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

201–210 of 239 posts

Re: How to reduce the cognitive load of your code

#201

Post by tekromancr »

emiliobumachar wrote: post #193
matthewtoast wrote: post #46

Code clutter is much more consequential than it gets credit for. Poor formatting, inconsistent whitespace, snips of unused code, and misleading filenames are speedbumps (or worse, spike strips!) that a developer is going to hit every time they sit down to code. And unlike bad abstractions -- which you can "learn" about and mentally model -- the friction of clutter is a constant damping to your productivity. Building…

What's a Linter?

It's a tool that finds things that aren't strictly errors in your code, but are likely to cause problems.

see also: https://en.wikipedia.org/wiki/Lint_(software) (this article refers to one particular (original?) lint tool, but there are numerous others for various other languages)

Re: How to reduce the cognitive load of your code

#202

Post by mavelikara »

ergothus wrote: post #182
yekim wrote: post #166

Earlier quoted context omitted.

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 exp…

  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
  ..
  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.
Will you be willing to extend the same charity to the bad Java code you have seen? Or do you have specific complaints for your harsh comments singling out Java?

Re: How to reduce the cognitive load of your code

#203

Post by Retric »

kazinator wrote: post #188
Retric wrote: post #162

Earlier quoted context omitted.

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.

The question is why you need a helper function? IMO, public functions are a special case and your generally better off using different naming schemes for internal and external functions.

Granted, if it's pure pass-through then reusing the name is a non issue. Foo(x){foo(x);} is not confusing. Foo(x){junk; foo(x);} is.

One option is Foo(x){validateForFoo; ValidedFoo(x);}

Alternatively for private functions JunkFoo(x){junk(x); foo(x);} And replacing JunkFoo with a meaningful name if possible.

Again though, public function Foo(x) should really call internal function Bar(x) otherwise it's really easy to couple things on both sides of an interface.

Re: How to reduce the cognitive load of your code

#204

Post by jkern »

Can_Not wrote: post #23
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.

Where I work, all the devs are lazy and incompetent... So I have to rush and overwork to get something that works.

...did you just call yourself lazy and incompetent?

Re: How to reduce the cognitive load of your code

#205

Post by mreiland »

the_af wrote: post #198
mreiland wrote: post #170

Earlier quoted context omitted.

> It seems like a reading micro-optimization to me, though. It's a "reading micro-optimization" in the same way that not littering your code with comments is a "reading micro-optimization". It makes you pause and interrupts your flow of thought as you contemplate something not directly related to what you were modeling in your head 2 seconds ago.

I don't think it's the same. I'm not arguing against code cleanliness or good practices. Code readability matters. I favor concise, expressive languages over verbose ones for precisely this reason. Littering your code with comments IS a huge readability problem. You are forced to filter them out to find the real code, since they are mostly garbage, but you can never be sure you aren't skipping some vital bit of infor…

> If your train of thought is interrupted every time you encounter them, you are way too novice a programmer.

You're unimaginative.

This conversation is finished.

Re: How to reduce the cognitive load of your code

#206

Post by Nadya »

Fargren wrote: post #110
hinkley wrote: post #48

Earlier quoted context omitted.

The code I'm working on now, and the code I worked on before that, was designed to be memorized. I suspect the only reason the team is productive is that they are working from long term memory most of the time. The insidious things about this are twofold. First, it makes all new team members look like idiots. These other guys are getting work done, what's your problem? Our problem is we can't figure out wtf is going…

Unit tests tell you what that small thing you did ages ago was meant to do, and what it does in different circumstances. If you have the discipline to thoroughly test your code(and the knowhow to not write brittle tests), it can really pay off.

>If you have the discipline to thoroughly test your code

This isn't the issue. I, and I suspect many others, simply don't have time to thoroughly test code.

It's the age-old issue of "Business doesn't rely on good code. It relies on delivering the product of that code." Up until the ship is both on fire and sinking - nobody cares about sailing a good ship. They'll settle for the shoddy lake boat and ride it out as long as it will last.

Re: How to reduce the cognitive load of your code

#207

Post by erikpukinskis »

Honestly, while I love these articles as food for thought, they really aren't the solution to the problem.

In my experience, programmers generally have a sense of what parts of their code need to be cleaned up. If they are a newer developer their ideas might be a little screwy. They might not see the root problems, but they know which closets are producing ghouls.

The issue I see is that developers don't think refactoring is a good a use of their time, or someone up the food chain doesn't think it's a good use of their time, or there's just so much institutional inertia making people question whether it's a good use of their time.

If you want your code to be better though, don't read about architectural problems, just take some time to fix the stuff you know is bad in whatever way you know how.

That's better than any article or class and it pays you money and it makes your code more fun.

Re: How to reduce the cognitive load of your code

#209

Post by ergothus »

mavelikara wrote: post #202
ergothus wrote: post #182

Earlier quoted context omitted.

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 exp…

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 .. 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. Will you be willing to extend the same charity to t…

If you're looking for me to say I'm biased and occasionally say some exaggerated complaints....yeah, that's true. But as I still feel the basis has reasoning, I'll continue to answer:

Yes and no.

For the bad Java code I've seen, Java does not bear the responsibility. (And I've seen my fair share of bad Java code because I spent 5 years as a Java dev in a place that had a collection of bad coders and worse code). I've also (since) seen great coders with quality code (in Java), but I definitely retain some bias from my earlier experience.

BUT, when your language design promotes certain things, then yes, that language takes the hit. For example, some of the Perl options are just plain terrible (e.g. changing 0 indexing) and Perl takes the blame. Perl also moved away from those, recognizing the errors. Books like Higher Order Perl (and associated efforts) came out to promote best practices.

Java expressly sought verbosity, and thus takes the blame for verbosity at the expense of clarity.

Other practices are encouraged by the community. That's a gray area - it's not the language at fault, but...it's common. These can range from small and almost petty (Perl promoted underscores in variable names for REASONS, while Java promotes camelCaseBecauseIGuessSomePeopleLikeToSquintToParseVariables.) Not really the LANGUAGE fault, but definitely an expectation. (and one I've grown accustomed to in the name of working with others). Other problems are larger (Kingdom of Nouns) - still not the Language fault, but you can expect it if you're dealing with the code.

Many a time I've tried to trace through some Java code...weaving through "Impl" classes and factories, trying to find where some piece of logic is implemented...only to find myself in an empty class definition. That's a fault of both encouraged practices and poor practices.

When people complain of poor Perl code, it's usually code that was either written by someone that didn't do that as their main job, code from newbies, or code that has changed hands repeatedly with no one trying to make it maintainable. Most any code will suffer in those conditions. Java, thus far, has had the worst overall quality of code in "professional" collections that I've experienced. But then again, I've really only seen code in any quantity in 3 or 4 languages, so....anecdotal experience is anecdotal and subjective.

(I have to give props to Python here...while I have a few nits about a few things, and I'm not well-versed enough to discuss code quality of anything I skim, I've seen a lot of code that was probably "bad" but nonetheless avoided some mistakes that are commonly made in other languages, particularly with new coders.)

Re: How to reduce the cognitive load of your code

#210

Post by hinkley »

Nadya wrote: post #206
Fargren wrote: post #110

Earlier quoted context omitted.

Unit tests tell you what that small thing you did ages ago was meant to do, and what it does in different circumstances. If you have the discipline to thoroughly test your code(and the knowhow to not write brittle tests), it can really pay off.

>If you have the discipline to thoroughly test your code This isn't the issue. I, and I suspect many others, simply don't have time to thoroughly test code. It's the age-old issue of "Business doesn't rely on good code. It relies on delivering the product of that code." Up until the ship is both on fire and sinking - nobody cares about sailing a good ship. They'll settle for the shoddy lake boat and ride it out as lo…

The trick is to get off the boat before its final voyage. Or if you're really smart, the penultimate voyage, so nobody thinks you were involved.

I think that's one area where executives and salespeople have acumen that us poor plebs lack in spades. I'm not saying it's a good thing, I just think we get left holding the bag.

Post reply on HN