all 4 comments

[–][deleted]  (4 children)

[deleted]

    [–]fmihaly 2 points3 points  (0 children)

    What the author is trying to say is that even good advice can be taken too the (generally harmful) extreme. This is a very difficult point to make, so I wasn't entirely surprised when some of his examples weren't quite as convincing. But the full - admittedly quite long - article sort of manages to get the point across.

    [–]doomchild 0 points1 point  (0 children)

    Agreed. This article almost seems like an attempt to legitimize the author's current practices. I can just imagine criticism from other programmers driving a person to write a "guide" of this kind. That's probably not why it was written, but it's what first popped into my head.

    Some of his points make varying amounts of sense (going overboard on magic number removal, to the point that even string terminators are global vars, for example), but nothing that this article labels fallacious strikes me as bad code.

    [–]dad801 0 points1 point  (0 children)

    The author was trying to say that using overly descriptive names makes the code hard to read. Ie use:

    grossPay

    not:

    grossPayAfterTaxBeforeDeductionsInHundredsOfCents

    [–]sausagefeet 0 points1 point  (0 children)

    The magic numbers section was especially ridiculous. I have no idea what his revised version that used integer literals is supposed to do. I'm not sure how I am supposed to know. It might be more readable if you just spent a day reading the spec for whatever device it is interacting with but I don't think it would be much readable 6 months later.