except MiXeD CapiTals.

While I realise that some coding styles recommend this practice, they are simply wrong. For those of us who actually type in code - rather than playing a video game with an IDE and hoping something compilable pops out, having to swap cases is a pain. If you want to seperate out distinct words in a variable/class name be sensible and use embedded "-"'s or something else that inserts whitespace (or close - to) without having to use two fingers to type one character.

"I can forgive every coding blunder except MiXeD CapiTals."

That's a coding style, not a blunder - you don't like, don't use it.

"While I realise that some coding styles recommend this practice, they are simply wrong."

Wow - not just nonsense, but arrogant nonsense at that.

"For those of us who actually type in code - rather than playing a video game with an IDE and hoping something compilable pops out, having to swap cases is a pain."

Bollocks. Learn to type. Nearly all of the people I work with have between 10 and 25 years coding, and don't seem to have a problem with typing mixed capitals (even if not all may like the style).

"If you want to seperate out distinct words in a variable/class name be sensible and use embedded "-"'s or something else that inserts whitespace (or close - to)"

What language are *you* using that allows characters like the usual arithmetic minus operator or white-space in identifiers ?

"without having to use two fingers to type one character."

..but still having to type 2 characters instead of each capital ? Sorry Pete, you're entitled to your preferences but mostly you're talking utter garbage.

tim

Then just learn to touch type - not only does it makes programming much faster in the end (including documentation, a vital part of programming), but your thumbs don't suffer as much.

There are plenty of free or cheap typing tutors in the Internet...

Would that not be everythingButMixedCapitals?

aka camel case? If you've got a programmer writing names with ranDom CapITals in them then yes, that person has a problem, but if he's writingLikeThis in order to makeItClearer for the reader then, sorry, you don't have an argument.

Good piece, and on the whole I agree with pretty much all of it.

A couple of points though...

I'll start with comments - I completely agree about the "why rather than what" paradigm - too often comments do not actually explain the philosophy behind the way something works, which can and does mean that when you come to work on the code, you get the wrong end of the stick and end up breaking it. Your comments on the lines of "...they get in the way..." and "...because they do not get updated..." are simply symptoms of lack of skill and/or outright sloppiness on the part of the coder though; there is no excuse for this. The other one which really gets me on my soap box is, of course "...it's self documenting...". I dread to think how many countless hours I have wasted pouring through other people's code trying to work out what is happening simply because the coder could not be bothered to comment it, and quite frankly, as the years have gone on, I'm getting to the stage where I simply can't be bothered to work through such code; life is simply too short. I don't know about you, but I don't have a microprocessor in my head and I don't understand code. I understand English, but not code; page after page of poorly commented (or often, completely uncommented) code is completely useless and utterly exasperating.

On to redundancy - it is is indeed irksome, and I have suffered many hours trudging through old code (often not my own) and making the same change/update many many times. However, it's a fine line between redundancy and practicality; you need to weigh-up extremely carefully at what point you choose to abstract something to remove redundancy. Otherwise you end up on the flip-side of the problem which is working through many many layers of abstraction and subroutine calls which in the end leaves you without a clear idea of what is actually going on on a higher level. This can bring its own problems with it in that it hides the nitty-gritty "too much" and so one ends up loosing sight of what is actually happening.

Other than the above, yep - I think you're right :-)

Re Mixed Capitals - I've been writing code for ...ooo ...23 years or so, and I've never got on with mixed capitals either. I don't have a problems writing them, but reading them is (to me) a pain.

To me,

this_is_a_very_long_useless_name

...is much easier to read than...

ThisIsAVeryLongUselessName

...but it seems I am in a very small minority. I can accept that, I just thought I would mention it. Just for the record, I also deeply dislike things like i_variablename (ie - indicating the type by sticking a tag on the beginning or end of the variable). It's messy, completely pointless (if you don't already know what the variable represents then you probably don't need to know) and totally redundant. Yuk!

...and yes, both these are style issues. Nothing to do with correctness.

If you don't want mixed case, program on a commodore 64 :)

I grew up on Java (in university using Notepad and the command line!) and thought camelCase was the One True Way(TM). Then I learned Perl. Underscores seemed weird for a while, but I got used to it. Now I use underscores in Perl and camelCase in C# almost without thinking. The only thing I had to learn in C# was that private methods use lower case starting characters and public methods and properties start with upper case.

Sorry. Back to the article. So I didn't learn anything earth shattering, but the indented code story was funny and it's good to be reminded of all this stuff every so often.

Wholeheartedly agree with every point made there Tim!

I use mixed casing in my code, and I do not "play video games with the IDE and hope it turns into something compilable". I actually find that pretty offensive.

Code is very personal, its a reflection of your thought train and your decomposition of the problem to a logical solution, so I am all for developers having a style that they like. Software is a craft, and like any other craft, craftsmen will perform the same task differently. Some may prefix variables with a char to denote its scope, others lowercase, others may do both. Note that this may evolve base on the capabilities of the IDE (e.g. I prefix all controls on a form with the type to make it easier to find in intellisense)

As for hitting the shift key being a problem for a developer? WOW. Are you kidding me!? I would find your attitude much harder to work with than a coding convention that mixes cases randomly (as opposed to pascal/camel etc). I would actually find dashes (or whatever) much more annoying than a case change.

As Tim said, coding style is not a coding blunder. This article was about a crazy monolithic method which is/was completely bad design, the code itself could have been incredibly well-formed and highly readible (provided you work the hscroll!). It was just a lame design.

You remind of the kind of developer that wants to bring back i/j/k/x naming conventions because they save your poor little fingers a little bit of effort. That little "time saver" gets a feature in every refactoring book, it will make you famous! How could we all be so wrong! We must be playing video games!

Is to write a book about wonderful "ideas", which's only problem is they become polluted/broken when they have to interact with reality :s

Get a decent keyboard Learn and learn type

Never had problems with typing camelCase/PascalCase - do have a problem with incompetence and complainers though :p

I'm quite enjoying this series but for every good point there's plenty more that makes me think the author is actually a chump who occasionally gets it right.

Am I supposed to believe that a professional programmer didn't know how to use his main tool - a text editor - to the extent he was about to reinstall the operating system rather than toggling line wrapping? That programmer was at least as much of an idiot, if not more, than the original coder. Nice message but obscured by the banality of the delivery.

"That programmer was at least as much of an idiot, if not more, than the original coder. Nice message but obscured by the banality of the delivery."

Well put that man.

"You remind of the kind of developer that wants to bring back i/j/k/x naming conventions because they save your poor little fingers a little bit of effort. That little "time saver" gets a feature in every refactoring book, it will make you famous!"

:D It reminds of the first time I did some teaching assistance - the Professor in charge had two pieces of advice for the undergrads studying Pascal

- use short names such as i,j,k x,y,z etc

- make variables global rather than function parameters

*shudder*

We had to quietly and gently steer them on a less dangerous course...

" How could we all be so wrong! We must be playing video games!"

It's a fair cop !

That deserves a special Dawkins award all for itself.

>I also deeply dislike things like i_variablename (ie - indicating the >type by sticking a tag on the beginning or end of the variable).

I agree that using i_variable to denote an int or szString for a zero-terminated string is a waste of time (and worse). This is called Systems Hungarian Notation.

But the original idea was that the "kind", not the type, of the variable should be encoded (Apps Hungarian Notation), and is a very useful naming scheme.

E.g. i_largest_element -- the _index_ of the largest element in an array, etc. Neither type checking or IntelliSense will give you this sort of semantic information.

See

http://www.joelonsoftware.com/articles/Wrong.html

for more on this.

I believe that comments should be kept to a minimum. I will also agree with the 'why' and not the 'what'. If you want to know what a piece of code does, reading the comments won't help. In fact, it will probably cause you to make wrong assumptions. Remember, the comments don't execute, the code does.

I think we all need to take one thing into consideration, and remember the fact that many of the developers we are speaking of do not have English as their first language.

We also need to remember the fact that everyone has their own unique style of coding and depending on the reason for writing the code, will determine how they anotate that. For example, if someone is simply writing code for a private project which will then be sent to the customer, then we should not assume that they will include comments, or at least comments that we expect to match exactly what we are looking for. Further to that, I don't think that it's really a right to be able to complain about something that was given to you for free in the first place. I know some people will be thinking, don't release something if it isn't complete, seriously though don't use it or read it, if you don't agree with it!

Manners, more than anything.

Designs don't emerge! Speak english, please.

Design is a priori, emergence is post facto.

Evolution doesn't "design" (unless you are a loony), emergence is an evolutionary behaviour.

Bah! Humbug! So, are you a loony?

Perhaps you are trying to avoid the "architecture" word?