Simple Ways of Reducing the Cognitive Load in Code • Hacker News Board

Re: Simple Ways of Reducing the Cognitive Load in Code

#161

Post by guelo » Tue, Jun 28, 2016, 7:18 PM UTC

jonhohle wrote: post #115

His second example to "modularize" a branch condition is not functionally equivalent in _most_ in-use programming languages: valid_user = loggedIn() && hasRole(ROLE_ADMIN) valid_data = data != null && validate(data) if (valid_user && valid_data) … Is not equivalent to: if (loggedIn() && hasRole(ROLE_ADMIN) && data != null && validate(data)) … His version will always execute `validate(…)` if `data` is not null regardl…

If validate() doesn't have a side effect then the short-circuiting doesn't matter. The micro-optimization of skipping the validation for performance reasons is premature optimization. If the performance optimization is necessary it should be stated more explicitly in the code then just being hidden being a && short circuit

I've always thought this kind of short-circuiting as an implementation detail of the runtime that should not be relied on, a hack from old school C that refuses to go away. I cringe when I see code that relies on it. It is not semantically obvious when a developer intends to use the short-circuiting trick vs when it's just inadvertently there. Of course part of the reason it lives on is because of our awful popular languages that require null checks everywhere but don't provide any syntactic help for it.

Re: Simple Ways of Reducing the Cognitive Load in Code

#162

Post by pyre » Tue, Jun 28, 2016, 7:22 PM UTC

jorgeleo wrote: post #51

"How can a new developer just memorize all that stuff? “Code Complete“, the greatest exponent in this matter, is 960 pages long!" First... do not memorize, but internalize, understand why they work, and when to apply which one. Use them to solve the problem of your code been read in 6 month by a serial killer that know your address. Second... 960 pages. If you really want to advance the craft, if you really want to b…

> Second... 960 pages. If you really want to advance the craft, if you really want to become a better developer, then you don't measure by the number of pages (what a sacrifice, I have to read), you measure by the amount of gold advice on the book. 960 pages is a lot of gold.

I think that comment on the page length was just on the volume of stuff that one would have to memorize if they were to memorize (rather than internalize) the knowledge.

Re: Simple Ways of Reducing the Cognitive Load in Code

#163

Post by pyre » Tue, Jun 28, 2016, 7:25 PM UTC

lmm wrote: post #121

pimlottc wrote: post #75

Earlier quoted context omitted.

Using intermediate variables is one of the most underrated tools to make code more understandable. It's the definition of something completely unnecessary from a technical standpoint that is all about conveying meaning and clarity to other programmers. And it can be used to help group and "modularize" chunks of code within a routine without necessarily going to the extreme of pulling out a separate subroutine, which…

I think people underestimate the cost of vertical length. It's less obvious in small examples, but there's a huge difference in readability between a class or function that fits on one page and one that doesn't, so it's well worth making individual lines a bit less readable if it means you need less of them.

The question here is with is "a bit less readable"? Many people with run with that advice and start playing code golf on a production codebase.

Re: Simple Ways of Reducing the Cognitive Load in Code

#164

Post by TeMPOraL » Tue, Jun 28, 2016, 7:27 PM UTC

jorgeleo wrote: post #51

"How can a new developer just memorize all that stuff? “Code Complete“, the greatest exponent in this matter, is 960 pages long!" First... do not memorize, but internalize, understand why they work, and when to apply which one. Use them to solve the problem of your code been read in 6 month by a serial killer that know your address. Second... 960 pages. If you really want to advance the craft, if you really want to b…

960 pages is a light reading IMO :).

One can hardly find a better time investment than reading a good book on a useful subject. Especially today, when quite often you can easily get access to the best knowledge mankind has on a topic. Books are awesome!

Re: Simple Ways of Reducing the Cognitive Load in Code

#165

Post by pyre » Tue, Jun 28, 2016, 7:29 PM UTC

jimbokun wrote: post #103

lenkite wrote: post #80

Earlier quoted context omitted.

Stream based programming is a paradigm that with some training and proper code indentation is much , much faster to read than a nested for loop. Once you get used to it,you can literally fast-scan code written in this style with the confidence that you are not missing anything. Also, assuming you do not use mutable state, it also has the advantage of being easily parallelizable without any code changes. (As well, as…

"Stream-based code is certainly not something you can read off the cuff." List transactionsIds = transactions.stream() .filter(t -> t.getType() == Transaction.GROCERY) .sorted(comparing(Transaction::getValue).reversed()) .map(Transaction::getId) .collect(toList()); I honestly think most programmers fluent in Java 7 programming, can guess this is finding "grocery" type transactions, sorting by "value" transaction prop…

> ("map" could be confusing, as this usage is borrowed from functional programming.)

On the other hand, both Python and Perl have 'map' as a built-in function. There has been spillage out of functional programming for a while.

Re: Simple Ways of Reducing the Cognitive Load in Code

#166

Post by effie » Tue, Jun 28, 2016, 7:29 PM UTC

amirouche wrote: post #137

lmm wrote: post #121

Earlier quoted context omitted.

I think people underestimate the cost of vertical length. It's less obvious in small examples, but there's a huge difference in readability between a class or function that fits on one page and one that doesn't, so it's well worth making individual lines a bit less readable if it means you need less of them.

> so it's well worth making individual lines a bit less readable if it means you need less of them What does it mean?

Our teacher of programming told us something like this: if your program has so many lines it cannot fit on one screen, it contains at least one bug, so don't make them, keep them short. I try to make all projects made of small files, where each one can fit on one screen. Great for comprehensibility and productivity (less scrolling). Sometimes, a procedure gets longer than one screen, so what one needs to do is to put as much source as possible on a line, so that the entire thing fits into one screen.

Re: Simple Ways of Reducing the Cognitive Load in Code

#167

Post by zenojevski » Tue, Jun 28, 2016, 7:40 PM UTC

lmm wrote: post #121

pimlottc wrote: post #75

Earlier quoted context omitted.

Using intermediate variables is one of the most underrated tools to make code more understandable. It's the definition of something completely unnecessary from a technical standpoint that is all about conveying meaning and clarity to other programmers. And it can be used to help group and "modularize" chunks of code within a routine without necessarily going to the extreme of pulling out a separate subroutine, which…

I think people underestimate the cost of vertical length. It's less obvious in small examples, but there's a huge difference in readability between a class or function that fits on one page and one that doesn't, so it's well worth making individual lines a bit less readable if it means you need less of them.

Intermediate functions :)

Re: Simple Ways of Reducing the Cognitive Load in Code

#168

Post by [deleted] » Tue, Jun 28, 2016, 7:58 PM UTC

guelo wrote: post #161

jonhohle wrote: post #115

His second example to "modularize" a branch condition is not functionally equivalent in _most_ in-use programming languages: valid_user = loggedIn() && hasRole(ROLE_ADMIN) valid_data = data != null && validate(data) if (valid_user && valid_data) … Is not equivalent to: if (loggedIn() && hasRole(ROLE_ADMIN) && data != null && validate(data)) … His version will always execute `validate(…)` if `data` is not null regardl…

If validate() doesn't have a side effect then the short-circuiting doesn't matter. The micro-optimization of skipping the validation for performance reasons is premature optimization. If the performance optimization is necessary it should be stated more explicitly in the code then just being hidden being a && short circuit I've always thought this kind of short-circuiting as an implementation detail of the runtime th…

[deleted]

Re: Simple Ways of Reducing the Cognitive Load in Code

#169

Post by Guvante » Tue, Jun 28, 2016, 8:06 PM UTC

jonhohle wrote: post #115

His second example to "modularize" a branch condition is not functionally equivalent in _most_ in-use programming languages: valid_user = loggedIn() && hasRole(ROLE_ADMIN) valid_data = data != null && validate(data) if (valid_user && valid_data) … Is not equivalent to: if (loggedIn() && hasRole(ROLE_ADMIN) && data != null && validate(data)) … His version will always execute `validate(…)` if `data` is not null regardl…

If you want to be really concise you could also remove the precondition that loggedIn returns true before calling hasRole and have it simply return false if loggedIn isn't true.

But it seemed to me that the important bit was two dependent conditionals, not this exact example.

Re: Simple Ways of Reducing the Cognitive Load in Code

#170

Post by joe_the_user » Tue, Jun 28, 2016, 8:16 PM UTC

jorgeleo wrote: post #51

"How can a new developer just memorize all that stuff? “Code Complete“, the greatest exponent in this matter, is 960 pages long!" First... do not memorize, but internalize, understand why they work, and when to apply which one. Use them to solve the problem of your code been read in 6 month by a serial killer that know your address. Second... 960 pages. If you really want to advance the craft, if you really want to b…

As books go, Code Complete isn't intended to be memorized but to be understood. I would imagine a coder already having an internal model of how to write code and using a book like Code Complete tweak and improve that model.

Also, I read something like Code Complete for the same reason I've read the parent blog. Even though I feel like I know the basic points here, writing good code inevitably is a trade-off and so one more idea of how to make the trade-off is useful.