Edit: the first example is clearly stepping through values in an array, and the other is flipping some bits and setting others... what's hard to understand about that?
a ^ c | d
(a ^ c) | d
a ^ (c | d)
I dislike some overuse of parentheses, but in this case I'd definitely use them.
a = b[i++]
a = b[i]
i++ // or even better,
// i = i + 1
// and unequivocally
// rejecting any
// compiler for which
// it might matter.
a = b[i++]
If you're going to be reading C code, you have to be familiar with certain idioms that might be unfamiliar to someone who doesn't know C.
I would certainly reject any compiler for which these:
a = b[i++];
a = b[i]; i++;
a = b[i]; i = i + 1;
As a writer, whether of code or natural language, you are responsible for the thought patterns your writing actually induces in the mind of the reader, the practical side effect of someone reading your code, and emphatically not whatever you intended them to think.
In this sense your defense of b[i++] just fails. It has nothing whatsoever to do with uniquity of the known value of i++, because that is already assuming something (familiarity with C syntax) that is dangerously foolish to assume of a code reader.
Especially when an effortless alternative exists (i = i + 1) that meets a much, much wider natural expectation about assignment and order of operations.
I’m not advocating for using it, per se, but I’d be shocked to find any C programmer who knows the latter but not the former.
I read through mountains of legacy Scala code while working on my first several projects, and have assisted dozens of other new developers (most of whom also have never once read or thought about Scala previously).
The assumptions people made in that codebase still give me nightmares, mostly over how foolish and lazy they are in little ways, little unexplained “self documented” things that create multi-hour stumbling blocks but which could have been written in a more “elementary” style in the first place (without sacrificing any necessary language features).
When I see things like, “any C programmer should know ...” I just slap my head in stupor. It just misses the point entirely. It’s of zero importance whatsoever to write code in language X in a style that benefits mostly only “people who know language X.”
Pretend you’re writing the code for a freshman intern who will look at it in 5 or 10 years with no prior knowledge of the language it’s written in, and now you’re in the correct ballpark for how to write professional software.
Is it too much to ask for someone to look them up if they find one they are not familiar with?
For me personally or likely for other experienced engineers, code compactness is a nice thing.
But this is unimportant, because nobody should be writing the code for me or with me in mind. Code compactness for the sake of other experienced engineers is an extremely stupid thing to prioritize above the simplicity of reading straightforward, separated operations that rely on as few concepts as possible.
Code compactness is nowhere near as important as concept compactness, because the latter appeals to all engineers, not merely to other experienced ones.
Anything that requires or introduces a new concept or mixes multiple concepts together is more costly in terms of hurting readability and maintainability than corresponding “longer” code that relies on fewer concepts.
It would perhaps be instructive if you could enumerate or point to what you consider to be a good set of concepts to work from. Clearly there are some absurd answers ("it's all NAND gates in the end"), but I don't imagine that's what you're thinking. Would you include functors? applicative functors? Different forms of memory management? APL/R/Numpy-style arrays? setjmp/longjmp?
It’s kind of like martial arts. You are encouraged to learn a huge variety of skills, mostly fundamentals but also esoteric advanced things.
But when it comes to actually using them in real life, you should try to avoid needing to use them at all costs, and even when you are absolutely forced to use the knowledge, use the simplest, most straightforward way to address only the problem at hand, never in excess or for personal interest.
It’s about self-discipline, to orient your code for the mind of an inexperienced novice despite the fact that your simple code might be solving state of the art problems.
It happens to all programming languages when engineers don’t prioritize future-proof readability as a first class part of maintainability along with testing and judicious choices about when to invest in extensibility designs vs when to ignore extensibility.
What does it say about the competence of "future" engineers if they can't understand code written by past ones?
One of my favourite sayings is "the code is unreadable to you, because you are not qualified to understand it yet". Perhaps we should not encourage the degradation of our craft.
It doesn’t say much about those future engineers at all.
It’s easy to write inscrutable code that even veteran engineers can’t understand, yet still “gets the job done.”
Also, you act like this would imply that all future engineers are the same, but that is not true and not related to my points.
You’re writing code for the inexperienced future engineer, some poor soul tossed into a legacy codebase without much help. It’s not their fault they were put in that position. It’s sink or swim. Good code helps _that_ person swim.
As for the quote you mention,
> “One of my favourite sayings is "the code is unreadable to you, because you are not qualified to understand it yet".
That is a horrible way of thinking, with built in condescending attitudes and everything. If code is unreadable to someone, beyond basic syntax definitions, that is the author’s fault and not at all the reader’s fault for being inexperienced.
The reason 5th graders can’t read Infinite Jest is because David Foster Wallace tried to make it complicated, not because, in some skewed perspective, the writing is perfectly simple but 5th graders just aren’t experienced enough yet. It’s a complexity property of the writing not of the reader’s brain.
With literature you can get away with this because there are extenuating arguments about artistic merit.
For business software, not so. In that case, if you write something more like DFW and less like Hemingway, it’s a sign of laziness and lack of self-discipline.. and not at all a sign of skill advancement.
Most code that creates value to people is messy, written in a hurry with vague specifications & unclear understanding of what the end user wants or would pay for, and it gets iterated by disjoint teams of people with competing timelines, politics, credit mongering and resource constraints, and most of it is for reporting something to someone.
If you don’t step back and realize that bare metal performance and esoteric data structures and algorithms generally don’t matter and can be picked up quickly by just about any engineer, and that real value comes from putting careful scaffolding and comments around hacked up business logic that needs to be future proofed against highly volatile business circumstances, you’re just going to be miserable and probably should quit and try to find a financially viable open source job on a compiler team or something where the exceedingly rare assumption you want to enforce (that most people reading your code are above average at the idioms of the language or tool you’re using) has some prayer of being relevant or applicable.
Let's not conflate the essential complexity of a problem domain with what's purely a result of grossly sub-standard development practices. And let's not pretend that the clowns are any better at coping with "real world limitations, deadlines, customer demands" - they're not.
To call it “substandard development practices” is like saying that wealthy people shirking their civic taxation responsibilities through offshore accounts is “substandard economic practices.” It just is.
with no prior knowledge of the language it’s written in
W...T...F...? Someone who can't understand the code they've been assigned to work on is simply unqualified for the job.
Nobody said anything like this! I don’t understand how you make this conflation mistake.
Before I ever read one single character of Scala code, I had written hundreds of thousands of lines of code in C, Python and Haskell, among others.
It was easy to understand Scala code despite having never read it except for places where people tried to rely on needless shorthand or obtuse ways of doing things.
I can’t understand your response. It’s so easy to write C code that a veteran C expert has to spend hours to understand, or to rewrite the same code in a way where a freshman who only ever used Java could equally easily understand it.
Familiarity with how to unlock meaning from badly written code is not the same thing as experience with a language.
If you want to read something in a language you don't know, you learn the language. Every profession has its own terms of art, its own abbreviations and lingo, and to suggest that those don't have any value is just ridiculous.
I seriously don't understand this attitude. You don't see other professions saying how they should be understandable by everyone who hasn't studied them. Why should programming be any different? I blame the "everyone can code" charlatans...
> “If you want to read something in a language you don't know, you learn the language”
but this means you’re missing the point. If you are writing something like a tech manual in Japanese, and you know ahead of time that it will be required that sometimes people totally unfamiliar with nuanced Japanese (but with high skill at picking up badic ideas in any language) have to rely on your manual, then how should you write it?
The foolish answer is to say you’ll write it with advanced Japanese language constructs and then turn around and say, “oh well, novices who want to rely on the manual should have gone and learned advanced Japanese.”
The smart answer is to say you’ll use self-discipline and restrain yourself from nuanced Japanese, and instead write in a way that novices have a good chance of decoding with minimal extra effort, and of course advanced Japanese readers will also still be able to get what they need too.
This is such a self-centered idea, approaching it like, “I can write whatever code I want using whatever idioms and it’s someone else’s fault if they didn’t learn the language sufficiently ahead of time before they found themselves needing to quickly read my code.”
a = b[i++] + c[i++]
a = b[i] + c[i]
i += 1Chances are you haven't been using C much for hardware/low-level stuff, because the ^ operator is seldom seen outside of that context.
On the other hand, the precedence of & and | (and likewise, && and ||) should be general knowledge: the former has the higher precedence, in analogy with multiplication vs addition.