Seven Ineffective Coding Habits of Many Programmers

>> Though my colleague prefers the rigor of Haskell and Elm, maybe I've got
>> a
>> small influence after all :) - unless it's only to please me...
>
>
> Interesting to watch. Thx Nicolas.
> I'm thinking Smalltalk must perform pretty well in the "name cloud"
> challenge.
> cheers -ben
>

> On 4/9/17, Ben Coman <[hidden email]> wrote:
>> On Sun, Apr 9, 2017 at 4:25 AM, Nicolas Cellier <
>> [hidden email]> wrote:
>>
>>> Hey, even if that should be pretty obvious things for an average
>>> Smalltalk
>>> programmer, a booster injection can't hurt.
> As the video is over 40 minuts (I have not watched it)
>
> Does this more or less capture the content of the video?
>
> http://notes.webutvikling.org/7-ineffective-coding-habits/
>
> 1. We clutter our code (with comments)
> 2. We write off the line
> 3. Parameters are placed all over the place
> 4. We don’t abstract enough.
> 5. We make complex methods with many parameters
> 6. We do lousy encapsulation
> 7. Testing should be a reflection of your functions
>
>
>>> Though my colleague prefers the rigor of Haskell and Elm, maybe I've got
>>> a
>>> small influence after all :) - unless it's only to please me...
>>
>> Interesting to watch. Thx Nicolas.
>> I'm thinking Smalltalk must perform pretty well in the "name cloud"
>> challenge.
>> cheers -ben
>>

> This was pretty interesting stuff. At first I was a bit worried that he was going to only concentrate on dead languages written in tedious fixed-font string editors with columns and …blech.
>
> His explanation of why you don’t want to make getters and setters in general and especially not off the bat and very especially not by default was very nicely done.
>
> I disagree with a lot about what he said about commenting though. Writing good clear code is so obviously important that we needn’t belabour the point. Where I object is the idea that having clear code is enough; the code can (when well written etc etc) tell you what it actually does BUT it cannot tell you what it was meant to do, how it is supposed to interact with other code, whether the current state of the code is considered complete (ie does it meet the original spec?) and so on. The code is what *is*. It provides no information about what was *supposed* to be.
>
> Ted Nelson once commented that programming ought to be part of the school of film and theatre (I think. I can’t provide a citation. Deal with it.) and I’m somewhat inclined to agree, because software is a story. You need a script, motivation, interactions, dialogue and you sure as hell need directors and producers.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: CEQ: Corrupt and Erase Queue
>
>
>