Sleepyjack

Hehe, first off, i hope you don't school me too badly cause i am still just a 20 year old learning some of the ropes.

That said, i must say that i am not that much of a code Nazi I actually just re-read part of a report i wrote at the start of last year to refresh my memory on some things, basically, the report was about measuring a rather significant piece of code (for one person especially ) of 80 classes and about 9000 LOC (the software did various image transformations and filters on images, like a amateur version of Photoshop or something) Anyway, don't want to bore you with my crappy assignment details...i am getting off track.

Back to Coding Standards. Quality of the code is ultimately the quality of the whole software (as it's pretty much the code which is the software!). There are many factors in determining the quality of the code, in reducing it to "good" or "bad". Since software engineering is far from being a precise mathematical science like any other engineering discipline, the rules for governing a lot of measurements are generally heuristics or "good practice". Now, you covered a few issues of coding standards, namely the meaningful variables names and some other purely aesthetic stuff (indents etc). For the most part i agree with you about rather pedantic standards, but i feel that there are some which are just bad.

Anyway i used RSM as a means of getting some quantifiable data about the quality of the code. As you can see, it can generate quality notices -> Quality Notices
If you care to look through some of them, some are a little pedantic and unnecessary (probably just bloating the process) but there are quite a few, that i thought was thought to be good practice to write good or was inherent in good quality code (ie eliminating the probability of bugs and errors in general logic/implementation
)
Here are a few specific examples of things i'd like people[bNOT[/b to do to any software project or code:

no goto statements -> Quality Notice 9
switch statements have a default condition -> Quality notice 13
if, for, while etc conditions not bound by {} -> Quality notice -> 22
no multiple returns -> quality notice 27
no breaks outside of case statements -> quality notice 44
oh yeah and the preincrement one

A real example of where that may have been unintuitive was my friend using last year in this software we were writing to identify particular shapes in images. Anway, he had an array in a while loop that he was accessing on some specific condition inside the while loop. Anyway he had the index increment as myArray[++index];

Anyway, the index was initialized as 0, so you can see the problem and how it can be a little unintuitive? To work then, the index would need to be set as -1 which i think is a little weird as an intilaisation value? I imagine that, that sort of confusion or whatever was what the quality notice was referring to. However i am glad that you said that it's a bad idea to use an increment or shortcut like that with other operators

I mean, that could be another quality notice. The number of operators you have on a line, if they exceed some value, that could be a quality notice. Because obviously, the more operators that are on a line, the longer it takes to work out what's happening.

There’s a lot of quality notices in that list which can have exceptions, although i feel that the things i listed above, shouldn't really have exceptions. To break them is going against that normally introduces "bad" code. Which basically means it's causes more problems or difficulties than normal. Also, as a logical linear flow, a few of those things will interfere with that, hence affecting readability or understandability. It could be like reading one of those adventure novels where it keeps saying go to page x, go to page y, stop here for a bit... etc. I thought it's universal that people like to read things as one nice continuous flowing work?

Some other coding standards i think are generally important, although not vital, are just naming conventions for classes, variables and constants. That just makes it easy to identify what is what type. Other stuff like declaring numeric values as constants, instead of just putting in numbers (ie for test conditions normally)
like if( x = 5)... instead if( x = NUMBEROFPEOPLE) ie no magic numbers

Ok, i don't want to go on listing heaps of crappy examples like this but i hope you get a general idea of what i am getting at. In sorta summing up this part, i'd like to say that coding standards aren't life or death, however, i would have thought that the time and effort put into abiding by a few of them, even moreso that just meaningful names, the less time is spent on deciphering the code by other people.

I don't want to come in and say one thing is more readable than the other, but from my little experience the more the code follows some of the particular standards it's easier to decipher. So the whole purpose is to have a similar set of rules set up by somebody which is meant to promote good coding based on previous experiences and heuristics, hence there's less probability of having bugs (or silly errors) when the code is being maintained by yourself or (especially) by others. So it doesn’t make other styles redundant or unacceptable. Just that it will take more time in the long run to get things together, cause they are different. It's meant to be the means justifies the end, in that the effort put in to get the code to these particular standards that are meant to promote good coding, logical flow, more simple statements instead of less complex ones etc will make the end process of when you have to fix it up, easier and less time consuming. And, of course, maintainability is the longest phase in the software lifecycle, so you want to make it as easy as possible!

I am finding it hard to get across my point that not ALL aspects of readability are subjective; well moreso that i'd had thought that humans like to read things in a logical flow, with identifiers with meaningful names and in common styles to promote their type it's all about trying to make things more clear cut and simpler for the uses. I am making an assumption that the more things there are in a smaller area the harder it is to grasp them all, cause they interlock etc and it takes time to distinguish them.
I daresay that the commenting of the code is as if not more important than the code itself. That's also a huge issue of readability, appropriately stating assertions.

Anyway enough of me crapping on for a bit, you say you worked for a large corporation, did they use coding standards or any kind of quality control and configuration management?

hehe, yep i already do information hiding. However you are saying code reuse is good, right? It's just you say avoid parallel information, which i think means the same information in different places, so code reuse would be good. Plus it makes bug hunting easier as you know the one place it's going wrong and can fix many things at once. Sorry, i am pretty sure that's right (i hope ) it's just you said avoid this technique and then said this includes. ahhh i think i've written way too much as it is.

Anyway i hope you can see, even just mildly, where i am coming from. I am not that much of a close minded code nazi, and i can accept other styles. I am saying that resources are usually saved if a general standard is implemented which helps promote quality code or intuitive logical to the average human programmer...

heh, this has been fun