Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to reduce the cognitive load of your code

chrismm.com

Post reply on HN
Print view View original

31–40 of 239 posts

Re: How to reduce the cognitive load of your code

#31

Post by HerpDerpLerp »

jt2190 wrote: post #17
HerpDerpLerp wrote: post #9

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…

Yeh I don't like abbreviations in code so would have unsafeName = Request("name") etc etc which does not have that problem... unless 'unsafe' is a thing in your business domain then things could get complex :)

The article goes on to advocate prefixing the methods that return safe and unsafe strings with 's' or 'us' I would hate that! I can easily see you ending up with string methods like safePadLeft and unsafePadLeft that do exactly the same thing but are named for where in the code they are used...

Coding is hard, and as other comments have stated all these blog posts and books need to be condensed into 'balance' and that balance point is different for each coder, project and team.

Re: How to reduce the cognitive load of your code

#32

Post by noxToken »

I've found that diagrams help. Young developers (in my experience) tend to laugh at the thought of making UML diagrams. At the very least, a class diagram will tell what classes references what. Using some custom stereotypes can help give further meaning.

Ideally, sequence diagrams (or a similar type) can help shed light on just how the project comes together. Explaining how a project works from a high level can leave unintended knowledge gaps. The great thing about these diagrams is that they can largely be automated with very few inaccuracies.

Diagrams are definitely now a silver bullet. I have found that they can easy grow unwieldy when attempting to incorporate too much information into a single diagram. Much like separation of concerns or the single responsibility principle, I believe that diagrams work best when they're focusing on a single piece of major functionality.

Re: How to reduce the cognitive load of your code

#33

Post by mtbcoder »

mathattack wrote: post #25
naringas wrote: post #11

I used to think that a lot of bad code out there was made by lazy, incompetent programmers... But then, after a certain job, I realized that this is probably not the case. Now I belive that most bad code out thare is made by overworked and tired programmers in a rush to deliver something that works.

It's both. Some of my worst code was to look at someone else's code after a manager shouted "FIX THIS NOW!!!" with some kind of quick and dirty hack, and then never going back to get it done right. I'm pretty sure this happens independent of whether or not I am any good. :-)

Happens to the best of us! Also, it's very difficult to keep entropy at bay in something that requires so much abstract thought and effort as programming, especially with how broad software's reach has gotten.

Re: How to reduce the cognitive load of your code

#35

Post by raverbashing »

jt2190 wrote: post #17
HerpDerpLerp wrote: post #9

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…

Joel advocates for correct Hungarian Notation, unfortunately people took it to put the language type of the variable (the compiler will check for that, obviously), but Hungarian Notation actually means you set a subtype to the variable so it helps with reading the code

You're not supposed to write

iLength = iCount * iSize

but rather (something like)

meterLength = unitCount * meterSize

Re: How to reduce the cognitive load of your code

#36

Post by ionforce »

noxToken wrote: post #32

I've found that diagrams help. Young developers (in my experience) tend to laugh at the thought of making UML diagrams. At the very least, a class diagram will tell what classes references what. Using some custom stereotypes can help give further meaning. Ideally, sequence diagrams (or a similar type) can help shed light on just how the project comes together. Explaining how a project works from a high level can leav…

What is a stereotype?

Re: How to reduce the cognitive load of your code

#37

Post by awinter-py »

Can_Not wrote: post #28
couchand wrote: post #13

The article is well-intentioned but misses the point in a few places. For example, the suggestion to have, in an MVC project, three top-level directories: one each for models, views, and controllers. This works fine for small projects, but larger projects can see significant benefit by keeping related code together. As with everything, it's a judgment call. The simple "one folder per type of thing" rule may not be ap…

Yeah, where do you add queues, events, observers, helpers, traits, interfaces, etc.?

Each of those should be a separate module uploaded to NPM. That was the versions can vary independently (for max compatibility).

This technique is named 'carbo-loading' (because of all the spaghetti).

Re: How to reduce the cognitive load of your code

#38

Post by boothead »

Biggest thing for me: have a small number of fundamental, composable abstractions. Be able to reason about how their properties interact when you combine them.

This is the main reason that Haskell is such a force multiplier for me. All the small minutia is well defined and it frees you to think about the big picture. Sure, it's a big learning curve, but so worth it :-)

Re: How to reduce the cognitive load of your code

#39

Post by a3n »

hyperhopper wrote: post #34

Even the first example is a bit silly. Nobody is going to not understand that (null == foo) is the same as (foo == null).

Agreed. I understand the desire to make the variable of interest more prominent, by putting it first, but that particular bug is well worth defending against.

Re: How to reduce the cognitive load of your code

#40

Post by mmebane »

gahahaha wrote: post #22
reacweb wrote: post #19

Earlier quoted context omitted.

Most of the bad code was made by very productive developers.

Because productive developers write more code or because productive developers write worse code?

Perhaps being a "productive" programmer requires understanding the requirements well enough to quickly write working code, then moving on to the next problem. Personally, I usually find that it takes two refactorings/rewrites to go from initial working code to something that I honestly believe is understandable/maintainable, and I don't always have time to do that.
Post reply on HN