Obviously code shall be easily readable when you need to understand it, for whatever reason (bugfixing, quality control, taking over the job and so on) which is not that actually important here in this context.
Of course.
I think the
point NorthGuy is making that we tend to give way too much attention to the readability of small pieces of expressions, while the "big picture" is orders of magnitude more important. Design, and documentation thereof. Data structures, algorithms (which are described in comments preceding functions, and at the top of .c file -
what the code does)...
I have had to modify/fix some projects with almost zero "hard-to-read" expressions, with all "style guides" followed, but due to bad higher-level design and documentation, and general bloatness, they have been major PITA - we easily talk about several human-months of work just to fix a trivial bug. OTOH, I have seen projects that reek like "fancy C oneliners", which look visually like crap and every line out of ten requires serious brain power to decode. Guess what? These projects can be
orders of magnitude easier to work with, than the previous type!
This is because we are talking about two different problems which are not strongly correlated, and while both are meaningful, they are in a completely different level of being a problem.
Consider fixing a simple bug or adding a trivial feature by a fairly experienced outsider. A broken-by-design implementation with neat coding style easily takes 100-200 hours to do anything with; a properly designed, but crudely written ?:*(++[]--)&* mess may take 10 hours of brain pain to do the same. In an ideal world, an ideal implementation would be studied and fixed in a few hours.
- - -
When in university, I was disappointed at the basic programming courses that mostly focused on bashing "goto" and the ?: operator, trying to prove that ?: automatically and always generates unreadable code; while things like higher-level software design, unit design and testing, documenting
what the code is doing in the comments was completely missing from the course.
"Software design" was a separate course, of course, but it was all about writing long user case documents (with little touch to the actual user or the actual coder), drawing UML diagrams and generating hundreds of pages of free-form textual representation. There is a glaring canyon between these two worlds:
1) Abstract, very high level "design" world, often not performed by actual coders, nor someone close to actual end-users. A lot of word documents and powerpoint slides. UML class generation happens with too little surface to the actual implementation, in a waterfall model (first two years drawing UML diagrams, then two years writing the implementation).
3) Implementation of said model (which cannot be modified at that point), where things like ?: operators or using "break" are The Evil, and if the end result is unmaintainable mess, it's not because of 1), but because of the bad coder who used ?: operator.
I can see this sounds quite extreme, but this line of thinking really happens and we really did see it in university.
I left 2) out. It would be a practical level of mid-level design, performed by the coders who are responsible for writing the code. There, the programmer thinks about their data structures, is allowed to modify the higher-level implementation specification, is given freedom and responsibility of designing the class structure, documents their modules and functions
in the source code comments (not Word document), to make the code readable
as a whole. And not only readable - but small and efficient, something that can only be done when the person closest to the computer running the resulting binary is allowed to participate in the design.
Single "hard to read" constructs are a ridiculously minor detail in this big picture.
Of course, a good programmer makes a good design, documented properly, and,
in addition, doesn't produce a single line of hard-to-read *?:&[++--] code.
On the other hand,
banning certain constructs
never helps anyone produce better code, because the better code exists on a higher level than that. If a certain person produces total unreadable crap, after banning the most ugly constructs, the code will still be crap; only a slight improvement is seen. But now it passes the stupidly simple and trivial corporate "style requirements", and we can pretend everything is OK.
There is a case of experienced programmers sometimes using constructs they understand very well, but beginners have trouble with. Banning such constructs may improve code readability, but
very slightly - after all, the beginner learns these constructs fairly quickly because they are just simple syntax, and their number if very limited - they
can be learned easily, unlike complex computer program design, which is a difficult task.
The world is full of totally shitty computer programs, yet the discussion about the reasons always ends up to some trivial syntactical detail which is almost meaningless in the big picture.