How to reduce the cognitive load of your code

Post by mathattack » Tue, Mar 29, 2016, 6:08 PM UTC

ktRolster wrote: post #67

mathattack wrote: post #25

Earlier quoted context omitted.

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. :-)

When you're really good, you learn to FIX IT NOW while also not making a hack. Your code becomes flexible enough to handle that kind of change.

Post by kilink » Tue, Mar 29, 2016, 6:13 PM UTC

gknoy wrote: post #117

msluyter wrote: post #75

Earlier quoted context omitted.

Re: "null != variable": I don't think it's necessarily confusing, it's just that usually we tend to think of the elements we're working with (variables, objects, functions, etc...) as taking on values, and so linguistically, we ask "is my thing null?" Not, "is nullness something that applies to my thing?" Hence "thing operation value" is arguably cognitively cheaper than "value operation thing." So you could argue th…

I think the point was, that as soon as you are aware that typos of "=" and "==" are common, and hard to catch mechanically, the _habit_ of using the (constant == myvar) pattern can suddenly be seen as having more value as a hedge against human error. I'd rather write it that way, and then later change it in code review to `(myvar == constant)`, than risk writing it as `(myvar = constant)` and have it sneak through. G…

Post by pm » Tue, Mar 29, 2016, 6:18 PM UTC

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.

Post by kilink » Tue, Mar 29, 2016, 6:19 PM UTC

berntb wrote: post #29

raverbashing wrote: post #20

Very good Until you have some code reviewer that thinks otherwise because of some "stupid reason" and you can't get around their hard heads. One example, breaking a 81 char line because it goes over the limit and getting two shorter lines that are awful to read So yeah I'll go for this when I'm working with reasonable people

So, what do you do if you get a job with Java or iOS and 30++ char method names? (Not being snarky, I would like to do some iOS development for fun but want lines under 78 chars, so it don't go over 80 with diff.)

Post by gknoy » Tue, Mar 29, 2016, 6:24 PM UTC

ergothus wrote: post #152

hbt wrote: 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…

    sort-foos
    sort-foos-helper
    sort-foos-merge-helper

    class FooSorter(object):

        def sort(self, foos):
            """Sort an iterable of Foo objects"""
            # ... sanity-check inputs ...
            self._sort(foos)  # do the sort operation

        def _sort(self, foos):
            """
            Sort things we already know are Foo objects.
            This is a helper for sort(), which already 
            sanity-checked our inputs.
            """
            # do the actual sorting