A road named NoNameUno

Now that I've gone thru first part of it. In my second part, I will try to explain my thoughts about goodness of a part of a program.  Any high level language will have some constructs about repetitive work ( usually called loop) and some decision constructs ( usually if-then-else). Other constructs are mostly immaterial for this discussion ...

For decision constructs I particularly look at the depth of the nesting, as well as composition of logics. For example, in a C or C++ construct, if I see the nesting of ifs are 4 or more level deep then I don't think it is a good decision logic. The reason for this is that if I draw a tree with all  the branches it soon becomes too complex. Try yourself, and you will see what I mean :-)

For composing too many clause within one if statement is also not very good. For example I would not consider the following if statement a good one even if the variable and constants names are very meaning full ( NoNameUno :-)

Bad if statement -

if ( X && ( !Y) && Z || Y && W )

I would not go into detail of this. If you see in a program not written by you, and you don't know much about the program, you might find it not being easy to comprehend. This requires refactoring.

For loops, first and foremost they should at most be 3 level deep. In other words, if the loops are nested more than 3 levels, it could become difficult to understand inside logic within the loop. There might be situation when inside logic is very minimal, but 4 or more levels of loops are needed. Only for those specific situations nesting at 4 or more levels can be cosidered good.

If a function has both iterations and recursion, then either that function is very elegant or very complicated. If it is hard to comprehend, it should be considered bad implementation.

Commenting functions, Naming variables, indentations etc. are mostly personal choices. Different places have different rules. Most of them are to make the code more readable/understandable for others, and often it helps. It is possible to follow these rules and still come up with very convoluted implementation of some logic. I personally try to see if something is really convoluted. How do I find it is convoluted? Just read some random function of a random source and try to understand what that function does. Then find out what  are not known to you (perhaps some other function it calls or other API it uses), if there are too many of those that were not explained in a comment line or such, then you know the function is not comprehensible.