Live data from Hacker News

How to reduce the cognitive load of your code

chrismm.com

181–190 of 239 posts

Re: How to reduce the cognitive load of your code

#181

'Avoid using language extensions and libraries that do not play well with your IDE' I'm of the opinion this should be extended to "does not play well without an IDE". Because even in projects that said "everyone, use Eclipse(/IntelliJ/whatever)", and tried to share project files, there was constant pain in ensuring that everyone had the same development environment ("Oh, yeah, I made a local change to my project file…

If something requires an IDE in order to run it, edit it, etc, that's kind of a code smell. The IDE might be masking complexity for you, but it is creating complexity on the server side or for developers who prefer to use something like vim. Getting something to build for the first time in Eclipse is a pain. So many settings that keep changing which menu they are under in different version and you have no idea what you are doing wrong. If I have to click through dozens of menus and type in values in order to get it to build for the first time that is another code smell. The ideal scenario is to check it out, run a single command for package bundling; setup; etc, and then run.

Re: How to reduce the cognitive load of your code

#182
post #166

Earlier quoted context omitted.

I agree with everything you said. As an old Perl guy, I found it hilarious that Perl has a reputation for illegibility, while I find it easier to read than most Java, because in Perl I can express my intent, and in Java it's buried in the noise. One cognitive problem I've not yet found a good solution to: So I have a high level routine to, say, sort the items in a display. Said sorting has some cascading effects, so…

Wrt Perl being readable / legible; I think most find Perl hard to read because there are 3-4 different ways to do the same thing. And many of the more "advanced" ways of doing things rely on short, terse single characters that act essentially like magic and behave differently in different situations. At least this is what I remember as I climbed the Perl ladder. Contrast this with say, Python, where readability is hi…

I won't disagree with most of what you said (though I will say that having one way to do it does NOT mean that said one way is particularly readable/maintainble - looking at you, Java).

That said, for every time I've hated that someone got terse and clever, I've loved that I wrote something that _read_ well, particularly when returning to previous code I don't remember. Coding is like a language, you can use that expressiveness to be terse, to be rambling, or to be clear. Learning to do so is a skill that has to be learned (cost), but can be more expressive (benefit). Languages (or patterns) that restrict that reduce the cost, and reduce the benefit.

Consider, for example, that Python takes great pride in it's explicit readability, and yet it chose "lambda" as a keyword (making no one happy outside of higher math), that "def" was chosen instead of "define", and that one of the most powerful parts of the language (comprehensions) are highly prone to using secret knowledge. [] works differently than (), for example.

So, what you've described are all valid reasons that Perl has a bad rep...but I don't blame Perl for them anymore than I blame JS for the hideousness that is the DOM, or Python for the bad scripts that have been written in it. Regardless of the language, cleverness and/or terseness without regard to future people (including your future self) is just not a good practice.

Re: How to reduce the cognitive load of your code

#183
post #158

I didn't appreciate how much of a difference it would make until I tried it, but now I know that one of the best ways of making code more comprehensible is to eliminate any questions about interactions between components by using a language with referential transparency. The results of functions should be determined solely by the values of their arguments, with no contamination by shared state and no side effects.

What languages are you referring to? What languages do not support referential transparency?

There's a significant difference between a language which permits it and a language which embraces it.

Re: How to reduce the cognitive load of your code

#184
Good advice, but it still seems like just cosmetics compared to the real brainkiller: (incidental) complexity.

It's kind of how legible handwriting is desirable, but not really the most important factor, when it comes to the amount of brain required to solve a math problem.

Re: How to reduce the cognitive load of your code

#185
post #27

There are so many similarities between writing code and writing English. - Thinking of paragraphs as functions with one purpose - keeping sentences short to reduce load on working memory and increase comprehension - create visual breaks to help the reader by grouping common stuff together as mini-functions - reduce intimidation factor of reading by removing convoluted stuff - remove cognitive noise (dead code, unnece…

I agree with everything you said. As an old Perl guy, I found it hilarious that Perl has a reputation for illegibility, while I find it easier to read than most Java, because in Perl I can express my intent, and in Java it's buried in the noise. One cognitive problem I've not yet found a good solution to: So I have a high level routine to, say, sort the items in a display. Said sorting has some cascading effects, so…

I always call the low level functions with some clear name related to the high level one by convention:

- sort_displayed_items_guts

- sort_displayed_items_impl

- ll_sort_displayed_items (ll == low level)

- do_sort_displayed_items

Re: How to reduce the cognitive load of your code

#186
post #17

He advocates prefixes on variable names. I would like to see good examples of this as I have never seen them as helpful (especially the tblUsers and intUserId type that can be common) .

Christian points to Joel Spolsky's example of using prefixes to add meaning, not type information like your examples. From Joel's essay: All strings that come from [user input] must be stored in variables (or database columns) with a name starting with the prefix "us" (for Unsafe String). All strings that have been HTML encoded or which came from a known-safe location must be stored in variables with a name starting…

I wonder how much of the later trend is due to the combination of early autocompletion and a codebase the size of windows or office, in a language where types can't be determined for sure without running each source file through the preprocessor. And most source files include the massive windows.h or some equally large hairball.

I assume that global variables would be horrible in such an environment, but typing out the prefix and maybe one letter of the actual name would cut the completion list down to a manageable size.

Perhaps apps hungarian started because it helped avoid common errors in complex GUI logic, then similar practices were carried over to the systems side where they were useful for mostly unrelated reasons, eventually reaching the world in general through the header files produced by the systems folks but lacking any of the context or history needed to go beyond "microsoft does it that way, there must be a good reason". Hopefully I'm just being overly pessimistic and extrapolating from massively insufficient information, though...

Re: How to reduce the cognitive load of your code

#187
post #158

Earlier quoted context omitted.

What languages are you referring to? What languages do not support referential transparency?

There's a significant difference between a language which permits it and a language which embraces it.

My tongue-in-cheek programming language selection rule: avoid languages that require punctuation to call a function -- like f(x,y), x.f(y), (f x y), or x f: y.

Re: How to reduce the cognitive load of your code

#188
post #162

Earlier quoted context omitted.

I agree with everything you said. As an old Perl guy, I found it hilarious that Perl has a reputation for illegibility, while I find it easier to read than most Java, because in Perl I can express my intent, and in Java it's buried in the noise. One cognitive problem I've not yet found a good solution to: So I have a high level routine to, say, sort the items in a display. Said sorting has some cascading effects, so…

One approach that can help is to name things based on what the functions actually do. validateSortDisplayedItems { validation Logic ... sortDisplayedItems(); //Actually sorts items. } This can be harder to maintain, but really long names end up a useful code smell.

The problem is that the validateSortDisplayItems is some sort of public function. The caller doesn't care about the validation, only that the items are sorted.

All kinds of functions everywhere validate their arguments; that doesn't deserve to be in their name.

Re: How to reduce the cognitive load of your code

#190
One thing I like which nobody ever seems to mention, is that when you divide your code into smaller functions it helps to have your functions actually take inputs and give outputs. It is very hard to read code which is just line after line of functions taking no arguments and returning nothing. No matter how descriptive your method names are, it will just end up being more confusing than if you simply wrote out all the code contained in those functions instead.

People need to see how the code flows and how things are logically connected. That is impossible to do with reams of methods operating exclusively on member variables.

I guess this is just another way of stating the benefits of functional programming. People do modularization at the function/method level so badly so often that I often think talking about modularization at class level, is beginning at the wrong end.

So many struggle with modularization at small scale.

Post reply on HN