Quantcast

Seven Ineffective Coding Habits of Many Programmers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Seven Ineffective Coding Habits of Many Programmers

Nicolas Cellier
A colleague of mine sent me this link: https://youtu.be/ZsHMHukIlJY

Hey, even if that should be pretty obvious things for an average Smalltalk programmer, a booster injection can't hurt.
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...


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seven Ineffective Coding Habits of Many Programmers

Ben Coman

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seven Ineffective Coding Habits of Many Programmers

Hannes Hirzel
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
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seven Ineffective Coding Habits of Many Programmers

Herbert König
Hi Hannes,

yes but more fun than your short list :-))


Cheers,


Herbert


Am 12.04.2017 um 13:41 schrieb H. Hirzel:

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seven Ineffective Coding Habits of Many Programmers

timrowledge
In reply to this post by Hannes Hirzel
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seven Ineffective Coding Habits of Many Programmers

Andres Valloud-4
Design documentation can be valuable.  Sports, play-by-play commentary
of what the code is doing, not so much.

On 4/16/17 11:37 , tim Rowledge wrote:

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

Loading...