• ChrisM@Work (3/26/2015)


    mister.magoo (3/26/2015)


    ChrisM@Work (3/26/2015)


    Phil Parkin (3/26/2015)


    dwain.c (3/26/2015)


    Gary Varga (3/26/2015)


    dwain.c (3/25/2015)


    ...I beginning to think that when I wrote this article (based on a quotation from Jeff):

    Make it Work, Make it Fast, Make it Pretty[/url]

    Maybe I should have entitled it" Make it Work, Make it Fast, Make it Pretty... and then Comment the Crap out of it."

    No!!! "Make it Work, Make it Fast, Make it Pretty... whilst commenting the Crap out of it." would be much better 😉

    I personally love that word whilst but at a guess Jeff being American would never use it.

    I'm British and I don't use it either 🙂

    Whilst, betwixt and amongst are in the same family of words, so unless you are prepared to use all of them (ie, don't use 'whilst' and then 'among' in the same document), it is more consistent to use none.

    I'd almost agree with this. Whilst and amongst don't appear to me to be uncommon, unless it's the HR folks I spend too much time listening to. Betwixt sounds too much like confectionary nowadays to be taken seriously. Who amongst us would dare?

    Whom amongst us??

    Unbeknownst to us, we have grammar police in our midst.

    what, grammar police? I've only seen a grammar violator - using "whom" for nominative case indeed, if we had any grammar police he be in the interrogationinterview room now.

    Incidentally, I sometimes use "betwixt" - but only in the phrase "betwixt and between", where it's redundant but can sometimes sound nice. Never yet in a code comment though.

    Somewhat more on topic: I disagree with those who think all commented out code is bad; there are several cases where it's rather useful: case (i): there are two ways of doing it, and one way is right for you current situation (data size, throughput requirement, required concurrency of access, and so on) but won't work well when requirements get a bit heavier and additional hardware capability is available; the other will be good when the requirements get a bit heavier, but is not suitable for use on the currently available hardware and is therefor commented out with appropriate comments indicating the situation. case (ii): the board of directors is engaged in internecine strife, and there are two versions of the requirement; we have code for both versions; the one that is currently losing at the board meetings is the one that's commented out. case (iii): we have two algorithms, both of which work well on small scale problems but we will have to handle large scale problems in future; we intend to switch back and forth between the two algorithms as and when larger scale instances become available until we've collected enough performance data to tell us which one will be best in the long term. There are probably plenty more cases.

    In none of these cases is more than a single procedure call or function call commented out - both procedures/functions are included in every build, but only one of them will be used.

    We have no desire to have a parameter which chooses which code to use, that just hands users a chance to screw things up.

    I've experienced. or been told about someone elses experience of, all three of my examples. Yes, this could be done without commented out code, but it would be a lot more error-prone: it is obvious to developers changing the not currently commented out code that they have to look at whether they should be switching to the commented out code instead or should be modifying the commented out code as well (and testing it and getting it through QA) according to the reasons for the changes, wheras if it's buried in documentation somewhere the current out version may be out of date and/or devlopers may end up re-inventing the current out version at far greater cost than just doing a switch.

    Tom