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

Re: Simple Ways of Reducing the Cognitive Load in Code

#111

Post by honkhonkpants » Tue, Jun 28, 2016, 3:48 PM UTC

jboy wrote: post #89

pimlottc wrote: post #79

Earlier quoted context omitted.

I agree with you, but honkhonkpants raises a good point - sometimes you must bow to existing convention, even if it doesn't meet current best practice.

"Sometimes you must bow to existing convention" is indeed a reasonable point, so I suppose I should clarify/refine my position. If you're implementing an STL-like container in C++, then absolutely -- you should stick with the convention: `empty`, `clear`, `size`, etc. To deviate from that convention would be an exercise in confusing the users of your code. You should make a note in the class comment that it deviates…

I think make_clear is just not good style. It conflicts in meaning with std::make_unique, which allocates a std::unique_pointer. When I see make_clear I think it allocates a new, empty object.

Re: Simple Ways of Reducing the Cognitive Load in Code

#112

Post by loco5niner » Tue, Jun 28, 2016, 3:54 PM UTC

ViktorasM wrote: post #62

Stopped reading at "Place models, views and controllers in their own folders". No worse way to organize your code than classify by behavior type. "Here are all the daos", "here is all business logic", "here are all the controllers". You add a feature as small as resource CRUD and scatter it's pieces across the whole code base. No.

Honest question from someone with little real world experience outside .Net: This is MVC's convention, to "Place models, views and controllers in their own folders", and it's what I'm used to working with. Can you point me to resources outlining other methods (responding with google "XYZ" would be fine too).

Re: Simple Ways of Reducing the Cognitive Load in Code

#113

Post by collyw » Tue, Jun 28, 2016, 3:56 PM UTC

reikonomusha wrote: post #105

collyw wrote: post #98

Get a decent high level architecture, good, consistent database design and you don't write anywhere near as much application code. Start hacking about using one field for two purposes or having "special cases" and everything starts to get messy. These special one off cases will involve adding in more code at the application level increasing overall complexity. Repeat enough times and you will code a big ball of mud.…

There's relevance in talking about both micro- and macroscopic guidelines. Both are important. Very rarely does someone "read" an entire code base "with one look" and be able to deduce issues. You do, at some point, have to get into the weeds. Managing that experience is what articles like these are about.

Yes, there is value in both, but I only ever see people talking about the former.

Re: Simple Ways of Reducing the Cognitive Load in Code

#114

Post by CuriousSkeptic » Tue, Jun 28, 2016, 4:01 PM UTC

reikonomusha wrote: post #107

CuriousSkeptic wrote: post #102

Earlier quoted context omitted.

Actually, not at all. It's directly measurable http://www.ncbi.nlm.nih.gov/pubmed/17833905 "The pupil response not only indicates mental activity in itself but shows that mental activity is closely correlated with problem difficulty, and that the size of the pupil increases with the difficulty of the problem"

My problem is precisely that these scientific methods are not used when "cognitive load" is being used as rationale. Wouldn't you agree that it would be a mistake for me to claim that cognitive load is an issue with something if e.g. I have not shown that pupils dilate (or some other reasonable experiment indicating correlation)? Unfortunately, doing these experiments is difficult, which justifies "hard to substantia…

Yes I do think claims should be justified by experiments. Perhaps I'm reading the wrong fora but it seems to me that serious HCI-studies on language design should be happening a lot more than it does.

Re: Simple Ways of Reducing the Cognitive Load in Code

#115

Post by jonhohle » Tue, Jun 28, 2016, 4:05 PM UTC

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 regardless of whether the user is logged in or has the appropriate role. Not knowing the cost of `validate(…)`, this could be an expensive operation that could be avoided with short-circuiting. It also seems somewhat silly (and I know it's just a contrived example), that a validation function would not also perform the `null` check and leave that up to the caller.

Re: Simple Ways of Reducing the Cognitive Load in Code

#116

Post by chimprich » Tue, Jun 28, 2016, 4:11 PM UTC

pimlottc wrote: post #75

iamleppert wrote: post #5

"Use names to convey purpose. Don't take advantage of language features to look cool." I can't say enough about this. Please write code that is easy to read and understand, not the most compact code, and not the most "decorated" code, or "pretty" code or neat because it uses that giant list expression or ridiculous map statement thats an entire paragraph long. Similarly what bugs me is when I receive a pull request w…

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 agree, intermediate variables are a highly underrated technique that can make code more understandable at a glance. What is annoying is that quite a few IDEs flag intermediate values that can be removed as a possible error, which probably discourages quite a few beginners from using them.

Re: Simple Ways of Reducing the Cognitive Load in Code

#117

Post by tigershark » Tue, Jun 28, 2016, 4:14 PM UTC

criddell wrote: post #20

tigershark wrote: post #9

Earlier quoted context omitted.

I completely disagree, every method can be split in private methods. In that way you don't need awful and unhelpful comments in the middle because you can understand what it does simply from the method name.

> you can understand what it does simply from the method name That can be tough sometimes. How do you handle the case where you've created a function just to package some block of code that would otherwise be repeated 40 times? You end up with function names like add_to_list_when_cromulent() or even worse rebuild_stats_helper() Or you have the situation where every time you do action A, it usually needs to be followe…

The first case is a self-explicative one liner, it doesn't need an external function.

    var evenNumbers = Enumerable.Range(0, 40).Where(i => i%2 == 0).Select(i => i);

Private methods must group non-elementary steps. The second case is a perfect example that explains why it is so much better to use a private method because now you have a method that groups both sub-methods and you don't need to call always two different methods in a bunch of places. In this way you decreased code duplication increasing clarity.

    private void ProcessLogs()
    {
        var events = _logProvider.Read();
        events.Where(e => e.IsError).ForEach(SendErrorAlert);
        events.Where(e => e.IsWarning).ForEach(SendWarningAlert);
    }

And the method name seems quite self-explanatory to me.

If you need to separate one method in paragraphs, and add comments that explain what each paragraph does then that code is SCREAMING for a refactoring, deleting all the useless comments and extracting that mess in properly structured Classes/Methods.

Re: Simple Ways of Reducing the Cognitive Load in Code

#118

Post by kaoD » Tue, Jun 28, 2016, 4:16 PM UTC

bdavisx wrote: post #100

kaoD wrote: post #39

Earlier quoted context omitted.

Here's John Carmack's take on the issue: http://number-none.com/blow/john_carmack_on_inlined_code.htm... TL;DR: He's in favor of inlining functions.

Actually, if you are inlining, he says: "you should be made constantly aware of the full horror of what you are doing." I wouldn't say he's in favor of it, he actually appears to be advocating for a pure FP approach. But if you have to, inlining is OK, with the quoted caveat.

That's literally the first paragraph in the article, keep reading. Also, I think you misunderstood it.

> if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing.

The horror he refers to is not inlining, it's dealing with stateful logic. If you are doing state it's better to be aware of the horror making it explicit by inlining rather than hiding the state changes via passing and receiving in functions.

I'm pretty sure he's advocating for inlining one-off functions.

Re: Simple Ways of Reducing the Cognitive Load in Code

#119

Post by sbov » Tue, Jun 28, 2016, 4:18 PM UTC

delecti wrote: post #31

iamleppert wrote: post #5

"Use names to convey purpose. Don't take advantage of language features to look cool." I can't say enough about this. Please write code that is easy to read and understand, not the most compact code, and not the most "decorated" code, or "pretty" code or neat because it uses that giant list expression or ridiculous map statement thats an entire paragraph long. Similarly what bugs me is when I receive a pull request w…

I recently got a code review that in several places suggested I switch to the new Java 8 stream API [1]. I just flatly responded that it was far less readable, even if I could condense a half-dozen lines of code down to one. Where I can quickly scan over a foreach loop to get the jist of what it's doing, I have to closely examine each call in the new approach to have any idea what it's doing. [1] http://www.oracle.co…

I think it's a familiarity problem. I felt the same at one time, but once I became more familiar with the operations, I found the stream API much easier to scan.

I was asked at work to explain why I prefer the stream library - other developers have lagged a bit on usage.

The first reason is, the method calls are designed to only do so much, and are named after what they're designed to do. Filter is for filtering. Map is for mapping. I can read the first word of each line to get an idea of what it's doing (filter sort map).

Another bigger reason for me is: you know exactly what code is generating those transaction ids. If you are interested in how the transaction ids are generated, it is damn obvious which code you need to look at. And if you aren't interested in how the transaction ids are generated, it is damn obvious which code you can safely ignore.

In comparison, what does a for loop do? It does all sorts of things, oftentimes several different things at once. As such, I leave for loops for more involved processing, and use the stream API for straightforward transformations.

Re: Simple Ways of Reducing the Cognitive Load in Code

#120

Post by prawks » Tue, Jun 28, 2016, 4:23 PM UTC

loco5niner wrote: post #112

ViktorasM wrote: post #62

Stopped reading at "Place models, views and controllers in their own folders". No worse way to organize your code than classify by behavior type. "Here are all the daos", "here is all business logic", "here are all the controllers". You add a feature as small as resource CRUD and scatter it's pieces across the whole code base. No.

Honest question from someone with little real world experience outside .Net: This is MVC's convention, to "Place models, views and controllers in their own folders", and it's what I'm used to working with. Can you point me to resources outlining other methods (responding with google "XYZ" would be fine too).

Django's recommended project structure is one that immediately comes to mind. A project is broken down into "applications" each which have their own models, views, and controllers (among other things like forms, tests, etc.). Each "application" is an area of responsibility within the project, like payment or user management.

As it's python, the 'views' module could technically be a folder with multiple files inside it, but they would all be grouped under their respective app.