When I write code, I keep the target audience in mind. That target audience is a maintenance programmer doing their first programming job.
What's a maintenance programmer? Sounds pretty derogatory.
Writing good code: how to reduce the cognitive load of your code
91–100 of 187 posts
Re: Writing good code: how to reduce the cognitive load of your code
#92I always feel guilty when using idiosyncratic code. A couple of jobs ago I briefly used this questionable Python idiom:
var = "%s code %s are bad"
var %= "Stupid", "tricks"Re: Writing good code: how to reduce the cognitive load of your code
#93I like code that reads like a Dick & Jane book ("See Dick. See Jane. See Dick run. See Jane run."). However, it appears to be trendy to write insanely difficult to read code. To use the analogy, Shakespearean code. Instead of one line of code doing one thing the developers will write a ton of functionality into one line of code by using fluent and method chaining. As someone reviewing the code I have to keep this men…
I love that term "Shakespearean code" — beautiful exploitation of the language, that when analysed deeply is amazing, but on the surface is just really fucking horrible to read.
Re: Writing good code: how to reduce the cognitive load of your code
#94Earlier quoted context omitted.
I can't up-vote this enough. As someone that started doing development in the late 80's, I find this style of coding to be infuriating. It completely destroys the ability to map lines of code directly to function calls without resorting to manual coding rules that require that each .function() be on a separate line, and makes debugging way harder than it needs to be. And, for what purpose ? To avoid a local, temporar…
When learning C in college, I was specifically taught to use CONTSTANT == variable. Accidentally omitting a '=' is common and putting the constant on the left side ensured the compiler would catch the mistake.
And there it is - thank you. I knew there had to be a reason, but couldn't quite figure out why and the example in the article (null != variable) was different enough to confuse the situation.
I haven't written anything in C in quite a while, and completely forgot about inline assignments. Which brings me to another pet peeve of mine, inline assignments... ;-)
Re: Writing good code: how to reduce the cognitive load of your code
#95I expected some science, however it's just subjective rules backed by nothing substantial.
That's because no one even knows how to start doing "science" in this direction.
When you read the code there are so many different things influencing your understanding that it's hard to impossible to even list them all. And if you take a look at some of the things that might influence your understanding you'll notice that most of them are very hard to impossible to measure.
From the top of my head, things which may have an impact:
* your level of skill in a given language
* your level of familiarity with the style of a particular programmer who wrote the code
* the tools you have at your disposal (go to definition, see docs functions of IDEs)
* your familiarity with a particular framework used
* your preference and expectations regarding the identifiers
* your knowledge of what the system as a whole (or its part) is supposed to do
* your familiarity with the project structure
Writing code is no more susceptible to scientific analysis than writing prose when it comes to other people reading the code (and not machines executing it). To write good code you need to first assume something about your readers (their level of skill, prior experiences, etc.) and then optimize the form of the code so that it doesn't confuse them (too short) or bore them (too long).
Seriously, writing prose and code (the latter only if meant for human consumption) is very similar: you need structure, things following one another, sentences of appropriate length and "density" and so on in both kinds of writing. Programmers could learn a lot from writers, but they most often refuse to do so. Literate Programming should be the default by now, yet is still used very rarely...
Re: Writing good code: how to reduce the cognitive load of your code
#96When I write code, I keep the target audience in mind. That target audience is a maintenance programmer doing their first programming job.
What's a maintenance programmer? Sounds pretty derogatory.
As I understand the term it's someone who inherits the feature-complete codebase after the original author left it. The duty of such a programmer varies depending on the place and project, but it's generally someone who will be asked to fix the bugs and implement new features should the need arise.
There's nothing derogatory to the term, although it's good to have some sympathy for such people - enough not to write bad code when first coding the project in the first place.
Re: Writing good code: how to reduce the cognitive load of your code
#97Earlier quoted context omitted.
I can't articulate exactly why, but that should totally be flipped. Should it? If you accidentally use an assignment operator (eg = ) instead of a comparison (eg === )[1] with the constant on the left your code will throw an exception, which is what you want. If you put the variable on the left and accidentally use an assignment then you'll overwrite the variable with the constant value and return true, consequently…
This 'reason' is as old as C, and it's always seemed to me like tying bells to your shoelaces because it would be bad if you forgot to tie them and tripped. I.e. the 'solution' is orthogonal to the problem. If you can train yourself to put the constant first, you can train yourself to use the right operator. And you can test your code.
If you can train yourself to put the constant first, you can train yourself to use the right operator.
Ideally, of course. But pragmatically mistakes happen. The point is that there's no cost - so why not use an explicit order and the right operator?
And you can test your code.
A lot of developers don't, or they only test for simple success cases that wouldn't catch this class of bug. It's scary.
Re: Writing good code: how to reduce the cognitive load of your code
#98Earlier quoted context omitted.
I can't up-vote this enough. As someone that started doing development in the late 80's, I find this style of coding to be infuriating. It completely destroys the ability to map lines of code directly to function calls without resorting to manual coding rules that require that each .function() be on a separate line, and makes debugging way harder than it needs to be. And, for what purpose ? To avoid a local, temporar…
When learning C in college, I was specifically taught to use CONTSTANT == variable. Accidentally omitting a '=' is common and putting the constant on the left side ensured the compiler would catch the mistake.
if (x = 5) is a default warning in clang (and I think gcc) nowadays.
Re: Writing good code: how to reduce the cognitive load of your code
#99Earlier quoted context omitted.
One-liners are bad if they are obscure and experienced programmers know that. However I wouldn't go as far as say that experienced programmers don't use one-liners at all. As usual in programming, it's all about balancing clarity/conciseness. For example, I find this much clearer as a one-liner (Python): validated_items = filter(is_validated, items) rather than validated_items = [] for item in items: if is_validated(…
Or: validated_items = [x for x in items if is_validated(x)]
I prefer the other one, because then I don't have to consider whether there is an outer variable 'x' that is being clobbered.
Re: Writing good code: how to reduce the cognitive load of your code
#100Earlier quoted context omitted.
When learning C in college, I was specifically taught to use CONTSTANT == variable. Accidentally omitting a '=' is common and putting the constant on the left side ensured the compiler would catch the mistake.
I would argue that by using CONSTANT == variable, you are reducing the cognitive load of the compiler, but increasing the cognitive load of the human reading the code (who has to mentally flip the expression around). I think the original article intended to say the same thing.
Compilers don't have cognitive loads.