101–110 of 281 posts
[1] http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...
TLDR: The author independently re-discovered what you may know as Old Code Syndrome. I think that's because mathematical papers place too much value on terseness and abstraction over exposition and intuition. This guy's basically in the position of a fairly new developer who's just been asked to do non-trivial update of his own code for the first time. All those clever one-liners he put into his code made him feel sm…
http://github.com/EGreg/Platform
I kind of developed that style organically as I went along, in both PHP and JS.
I tried to make the output readable as well. I've seen many frameworks output a bunch of gibberish, but with today's bandwidth it's not such a big deal to add a little bit of whitespace and make everything readable. Here's a fairly complex application, you can view the source of any page:
TLDR: The author independently re-discovered what you may know as Old Code Syndrome. I think that's because mathematical papers place too much value on terseness and abstraction over exposition and intuition. This guy's basically in the position of a fairly new developer who's just been asked to do non-trivial update of his own code for the first time. All those clever one-liners he put into his code made him feel sm…
This happens to me all the time. I have a very popular illustrated post on Monads titled "Functors, Applicatives, and Monads in Pictures"[1]. When I wrote it I thought it was the best monad guide ever. Now, reading back, I can see that some parts are confusing. I still see a lot of people liking it, but three years later I wish some parts of it were better. [1] http://adit.io/posts/2013-04-17-functors,_applicatives,_…
I now question the need to fully understand sometimes why not use libraries as per example and cargo cult a little to build up intuition. Then later get a more formal understanding.
Earlier quoted context omitted.
> I don't see comments helping me... I don't know why people say this type of thing, as if there's some choice you have to make between good names and comments. You can have both, and there are absolutely times when comments are necessary . Too many comments may be a "smell", but code that doesn't require any comments at all is very unlikely.
> there are absolutely times when comments are necessary . I'll have to take your word for it, because I've yet to run into that situation.
Sometimes comments are just to save future you some time or help other developers find context.
Suffice to say any project of significant complexity will probably require comments at some point. That complexity can come from the code, the task, the stakeholders or the dependencies.
Unless you are happy with a method name like getSimpleProductInstanceThroughCoreFactoryBecause ModuleRewriteWillBreakCompatibilityWithSecurity PatchSUPEE5523 ()
In that case I guess you're right.
Edited to stop the method name stretching HN layout.
Earlier quoted context omitted.
I can totally relate and to this day I describe one of my greatest failures as a manager as analogous to how "easy" math was to me. Until Calc II I really found nothing about math challenging at all. The result of this was that everyone wanted me to tutor them in math. The problem was that I didn't solve math problems like other people did, in fact I had no idea how I did what I did. I just did it. As a result when I…
This is why I have always found proofs difficult. I just don't know what steps people think are important to spell out but.
Earlier quoted context omitted.
> I don't see comments helping me... I don't know why people say this type of thing, as if there's some choice you have to make between good names and comments. You can have both, and there are absolutely times when comments are necessary . Too many comments may be a "smell", but code that doesn't require any comments at all is very unlikely.
> there are absolutely times when comments are necessary . I'll have to take your word for it, because I've yet to run into that situation.
Comments are for why.
Sometimes the why is obvious, then you don't need a comment. The rest of the time, add that comment. Even if it's something like "Steve in accounting asked me to put this in."
He should have asked: is this actually "knowledge" as they say academia brings to society? Is the money researchers earn being well spent? Did I actually deserve to be remunerated by this piece of work no one understands -- and, in fact, no one has read except for maybe three people?
Earlier quoted context omitted.
A good marker for when comments are going to be useful is when something stumps you, and then you fix it and/or figure it out. Chances are, when you read the code again it will stump you again - or on re-reading you might not even realize there was an issue. So I comment the change. It's usually something simple like, "This cast avoids a special case in method X", or along those lines. The comment is the "why" where…
If I run into that situation, I refactor the code so that I can better understand it the next time. To not do so is to waste all that time you spent understanding it. > It's usually something simple like, "This cast avoids a special case in method X", or along those lines. If I had an issue like that, I'd fix method X to be more accepting of unclean inputs.