Author Topic: Seven Ineffective Coding Habits of Many Programmers  (Read 13369 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Seven Ineffective Coding Habits of Many Programmers
« on: October 07, 2018, 06:43:35 PM »
YouTube: Kevlin Henney - Seven Ineffective Coding Habits of Many Programmers  (~45 minutes)

It was good. Kind of entertaining too. Covers a number of high level considerations in programming, mainly about communicating intent. It discusses things like whitespace, indentation, line wrapping, variable naming, encapsulation, and testing. He talked about how you should write tests based on usage rather than simply to call the methods, with an emphasis on the "Driven" in Test Driven Development.

It was worth watching, even for experienced programmers, yet quite simple and accessible even for fairly new programmers.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #1 on: October 07, 2018, 07:35:08 PM »
Wish there were transcripts of these things. I hate watching videos like this, I'd rather read them.

Will have to check it out sometime when I have 45 minutes free.

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #2 on: October 08, 2018, 07:05:48 AM »
Thanks for posting.

I liked the reference to Douglas Crockford's, JavaScript The Good Parts and his following jab at JavaScript.

Good insights into treating your code as a manuscript that is meant to be read by others. I agreed with the curly brace comments for separating the function arguments from the body of the function.

I really appreciated the parts about not justifying argument lists or comments at some arbitrary indentation like:
Code: [Select]
int FairlyLongFunctionName(int argument1,
                           int argument2);

It always creates a nightmare when refactoring a codebase by changing the function name size.

Or not separating the list on different sides of the screen (which I am guilty of fairly often):

Code: [Select]
int ReallyLongFunctionNameThatShouldBeShortened(int argument1,
    int argument2);

I used to be really good about trying not to spill past 80 chars on a line. In fact, when I was a newer programmer, I used to print my code out and edit it on paper with a pen. Then I'd go in and make the changes. I found myself constantly fiddling with how to break the code across multiple when long functions were encountered. It also made for annoying refactors when function names, or number of arguments was changed, which is part of the reason I stopped doing it.

I still need to work on my unit test writing as well, which the video reminded me of.

-Brett

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #3 on: October 08, 2018, 11:27:49 AM »
Without having watched the presentation yet (now I really want to get into it), the last example you have with the really long function name, at least for me, indicates that the function does too much and needs to be refactored.

As for having too many parameters, except in rare cases (like in NAS2D::Renderer's drawing functions which make sense to have a lot of parameters for drawing functions), generally I will break off many of those parameters into a struct or public class and take a reference to that instead. E.g.:

Code: [Select]
void someContrivedFunction(int with, int lots, const std::string& of, const std::string& parameters, float that, float are, float better, char* off, char* in, char* a, char* structure)
{}

would become:

Code: [Select]

/**
 * This can now be stuffed into a header somewhere so
 * it's out of the way. Also, the struct can be better
 * documented versus having a giant documentation block
 * for the function parameter list.
 */
struct StructOfRelatedData
{
    int Int1;
    int Int2;
    const std::string String1;
    const std::string String2;
    float Float1;
    float Float2;
    float Float3;
    char* Buffer1;
    char* Buffer2;
    char* Buffer3;
    char* Buffer4;
};

/**
 * Much cleaner interface. Also, less likely to deal with cache hits or whatever
 * issues come about with functions that have huge parameter lists.
 */
void someContrivedFunction(StructOfRelatedData& _s)
{}

Again, this code is very much contrived and assumes that the data moved into a struct is used in multiple places.

Hell, even the NAS2D::Renderer draw functions I mentioned could be better served with a different design paradigm (e.g., having a separate function call that sets drawing colors versus putting the color information in the function paramter list but now we're getting into design and architecture choices of an API).

Offline Arklon

  • Administrator
  • Hero Member
  • *****
  • Posts: 1267
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #4 on: October 08, 2018, 03:28:06 PM »
I used to be really good about trying not to spill past 80 chars on a line.
I personally find 80 chars per line too restrictive, even with 2-space idents. 120 chars is also pretty conventional and I find it much nicer to work with.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #5 on: October 08, 2018, 05:10:23 PM »
I used to care and then realized it didn't matter anymore. Sure, there are those still working in console mode but eh, modernize and grow up or don't complain.

But I'm also kind of a dick. :)

EDIT:

Okay, I'm watching it now and FINE, I cede defeat on the code is too long thing. He's kinda right. I will also state that I think my code tends to stick with 40 - 60 columns or less with only some code getting longer than that. It's a good indication that logic is getting too complicated. This of course is disregarding tab length so let's assume tab size of 4 spaces.

He does touch on the naming issue which I think has a lot to do with lines of code that run on forever -- if you're overly verbose in naming your thing, you have a different problem.
« Last Edit: October 08, 2018, 06:05:55 PM by leeor_net »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #6 on: October 10, 2018, 02:26:13 AM »
Thank you Brett for the code examples!  :)

(I think that was the transcript that Leeor required. ;) )

I suppose we should add an example of one of the better ways to write and justify parameter lists:
Code: cpp [Select]

void SomeRatherLongOverlyVerboseFunctionName(
    int param1,
    int param2
) {
  // ...
}

The parameter list is then kept together as one unit, with consistent indentation that depends only on structure, and not on name lengths. In particular, if someone renames the function to have a different name length, you don't have to re-justify the parameters to maintain a consistent indentation, and the parameter list is not split across both sides of the screen.



Leeor, that's a good point about passing a struct reference, rather than a bunch of individual parameters. There are many cases where that's the best way to do it. I suppose it depends on context though. If the parameters would be naturally bundled together, it makes sense to exploit that. If they are not naturally bundled together, or would need to be bundled together just for this one function call, then maybe not. I'd probably prefer a long parameter list than bundling together parameters in a forced artificial way. Though certainly long parameter lists can be a sign that something about the design is not so great.

As an example, here's a method with different levels of parameter bundling:
Code: [Select]
void DrawRect(int x1, int y1, int x2, int y2, unsigned char red, unsigned char green, unsigned char blue);
void DrawRect(Point p1, Point p2, Color color);
void DrawRect(Rect rect, Color color);

void SomeMethod() {
  /* Parameter meaning is not so clear at point of call */
  DrawRect(5, 10, 10, 20, 30, 50, 10);
  /* These two are more self documenting, without needing comments */
  DrawRect(Point(5, 10), Point(10, 20), Color(30, 50, 10));
  DrawRect(Rect(Point(5, 10), Point(10, 20)), Color(30, 50, 10));
}

On a related matter, when constructing a Rect, there is a choice of parameters, which might not be immediately clear:
Code: cpp [Select]

/* Parameter list types are identical, so you can't have both overloads. Choose only one. */
Rect::Rect(int x1, int y1, int x2, int y2);
Rect::Rect(int x1, int y1, int width, int height);

/* These options are more clear, and can both be available at the same time */
Rect::Rect(Point p1, Point p2);
Rect::Rect(Point p1, Vector size);




The 80 character limit does seem a bit archaic. Even if you're using a terminal, modern systems still allow terminals of varying sizes. Granted, I default mine to 80 characters wide, so there's that. At any rate, I don't particularly mind a limit of 120 characters, or pushing past the margin just a little, but by and large, I prefer code to be largely left justified.

His comment about how people read was noteworthy. We read in columns, like newspaper articles. I've heard elsewhere, that's much easier on the eye, and takes less effort to move the eye from one line to the next without losing which line you're on. Though I suspect that's less of a problem with code, since the greatly varying lengths of most code lines already creates a visual indicator that can help your eyes track which line is which.

At any rate, I've long found these widescreen computer monitors a bit silly. I spent most of my time on the computer reading, and yeah, I prefer to read in a column, than going all the way across a wide screen monitor. I've long felt computer monitors were being expanded in the wrong direction. I'm sure widescreen is just fine for movies, but it's not what I want for reading. Curiously, I once got a monitor at work that could be swivelled 90 degrees, so it was tall rather than wide. One of the selling features was being able to see more lines of code at one time. The only problem though, was the monitor's viewing angle was not the same between top-bottom and left-right. In normal widescreen mode, it seemed fine, with a decent viewing angle to the sides, but when you rotated in 90 degrees, it had a rather narrow viewing angle to the sides, which affected color display. In the end, the lackluster viewing angle meant I never bothered to use it in tall mode. Would have been nice though.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #7 on: October 10, 2018, 12:27:44 PM »
Technically speaking most of these widescreen monitors can be turned to make them taller than they are wide. And to play devil's advocate, with window snapping a wide screen monitor makes more sense if you have a single monitor layout -- e.g., you can have two narrow windows side by side if you're doing comparison (e.g., code diff, etc.).

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #8 on: October 11, 2018, 03:33:20 AM »
Err, yes, though turning a monitor sideways is awkward if you don't have the mount or stand to support it. That's what the feature was, a monitor stand that could swivel 90 degrees and lock in place. And some software support to also rotate the image 90 degrees to match. Would be kind of hard to use without both.

I did end up using side by side windows. It was a dual monitor setup too, both widescreen, so I ended up with 4 blocks of windows. It completely filled my field of view. I didn't really need it though, as I spent the vast majority of my time focused in one window. I would have preferred more vertical screen space, and would have been willing to sacrifice horizontal space for it.

Doesn't matter how wide a screen is, if it's not also sufficiently tall, it still feels like looking through a microscope.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #9 on: October 11, 2018, 09:26:35 PM »
Well, I watched the video. The guy talks slow enough that I was able to watch it mostly at 2x speed, so that helped cut down the time. :)

Anyway, I was going to write up a post about what I agree and disagree with. But ultimately I realized that despite the fact that coding style can easily be an exact science, it isn't and likely never will be. We've injected human feeling into a system that doesn't need it, and people will always continue to be abnormally bonded with whatever coding style they personally prefer.

I think I can summarize it back to a debate which has appeared even on this forum: tabs or spaces for indent? Two or four? etc...etc...

Although I will say it was mildly entertaining to watch someone express their preferences as the way to be. I must admit, at one point, he stated that some of this was his preference.

What I've found more than anything is that particular style doesn't matter (well, it does, but also doesn't). What's maybe more important is that once a style is set, people are willing to actually follow it...and not subtly undermine or intentionally ignore it due to their own preference. I.e. Just because you prefer to use four spaces doesn't mean using tab is /wrong/.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #10 on: October 12, 2018, 07:11:42 AM »
Quote
We've injected human feeling into a system that doesn't need it

I'd like to claim you've spoken to my heart with that statement, except I'm not sure I have one. ;)


Next up, Vim versus Emacs :P

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #11 on: October 12, 2018, 07:59:03 PM »
White Claw,

I would say style does matter. While there isn't a single right answer in how code should be formatted, there are definitely wrong answers. I have worked on code that was poorly formatted. It isn't fun. Actually, I find cleaning code fairly enjoyable sometimes, but working in the code before it is cleaned is tough.

I'm not sure that I am, but I would like to be liberal on enforcing style rules on others. Nothing is worse than tearing apart decent code that someone worked hard on because like you said there was a tabs instead of spaces or whatever. Especially when it is all freelance coding.

-Brett

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #12 on: October 12, 2018, 08:05:52 PM »
Next up, Vim versus Emacs :P

You're fired.

Nothing is worse than tearing apart decent code that someone worked hard on because like you said there was a tabs instead of spaces or whatever. Especially when it is all freelance coding.

Fair enough. There is really terrible formatting but beyond that I think White Claw has a point with consistency -- consistency is generally more important than style.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #13 on: October 12, 2018, 10:22:46 PM »
Agreed on consistency. I hate when code has inconsistent formatting. It's especially bad if there is a tabs/space inconsistency, and the tab width is not even between developers. That leads to all kinds of awful indentation.

Whenever I see inconsistently formatted code, I find I want to clean it all up. Realistically, that can generally be done by code formatting tools, so probably a waste of time to do it manually. Unfortunately, if you run a poorly maintained project through such tools, it tends to create massive changes throughout the code base. That's not so bad if you're working solo, but if you're working in a team, and other people have checked out branches they're working on, there's a good chance you'll be creating a ton of merge conflicts for everyone on the team.

Global changes, such as project wide formatting changes, or restructuring the directory tree are best done when other people don't have active work in those areas.

It's preventable though. You can have code checking tools that either prevent a push from being accepted by the upstream repository, or flag a pull request as not clean if there are code formatting issues. That lets you keep on top of things, and fix them before they become part of the master branch.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #14 on: October 13, 2018, 12:14:49 AM »
Visual Studio is actually really good at this, particularly in C#. It offers a lot of ways to be consistent. It even offers suggestions on how to improve initialization, function/class naming, etc. It's really astonishingly effective.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #15 on: October 13, 2018, 02:41:00 AM »
I would say style does matter.

Perhaps my statement wasn't fully articulate. By "...that particular style doesn't matter..." I mean that the /particular/ style doesn't matter. Not that style, in and of itself, doesn't matter. I don't mean to imply a willy-nilly free-for-all is the way to go.


Separately...

Quote
I have worked on code that was poorly formatted.

And I'm not sure how to fully articulate this either, but I'll try. The thing is, it's sometimes a matter personal taste as to what is poorly formatted. But what if the entire code base was poorly formatted in an exacting and consistent manner, and the entire development team used and understood that formatting style? Is it easy to integrate new team members...maybe not. But then again, neither is having five or ten different "right answers" in the code base.

I think I'd rather have a team of terrible formatters who are willing to be consistent, because I can at least hand them a cleaner standard with confidence that they'd follow it.
« Last Edit: October 13, 2018, 02:42:31 AM by White Claw »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #16 on: October 13, 2018, 07:06:18 AM »

Offline lordpalandus

  • Banned
  • Hero Member
  • *****
  • Posts: 825
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #17 on: October 13, 2018, 01:49:13 PM »
Interesting...

I notice that it isn't mentioned anywhere of properly documenting the code. If you properly document the code, you can make up for a lot of bad code styling. And if you combine good documentation with good styling, then it is a breeze to read through complex code.
Currently working on Cataclysm of Chaos, Remade.
Link to OPU page = http://forum.outpost2.net/index.php/topic,6073.0.html

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #18 on: October 13, 2018, 02:05:38 PM »
Code should be self-documenting. Documentation (aka comments) should explain assumptions made by the code but the code itself should be documentation enough.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #19 on: October 13, 2018, 11:06:09 PM »
Sometimes the best comment is no comment. If the code is written cleanly, with good names, comments shouldn't be required most of the time. The problem with comments, is they are not compiler checked, and so they can get outdated and not match with the code.

For an external source that says similar, you could read The Clean Code Collection.

It's also worth pointing out that many comments you do see in the wild so closely match the original code so as to be completely redundant and unnecessary. They just create noise, and train people to ignore the comments.

Offline lordpalandus

  • Banned
  • Hero Member
  • *****
  • Posts: 825
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #20 on: October 13, 2018, 11:14:31 PM »
You are right, code should be self-documenting. However, very few programmers have that skill. That or they are too rushed to make good self-documenting code.

Actually the issue of being rushed, is often why coding style is horrific. 

Currently working on Cataclysm of Chaos, Remade.
Link to OPU page = http://forum.outpost2.net/index.php/topic,6073.0.html

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #21 on: October 13, 2018, 11:17:51 PM »
I notice that it isn't mentioned anywhere of properly documenting the code.

I thought there was a section in the video about this? Perhaps it was another video I watched recently.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #22 on: October 14, 2018, 12:51:12 AM »
You are right, code should be self-documenting. However, very few programmers have that skill. That or they are too rushed to make good self-documenting code.

Novice programmers lack this skill. Any experienced developer that has a good grasp of their chosen language is perfectly capable of developing self-documenting code. Saying this is a skill most programmers lack is a demonstrable falsehood.

Actually the issue of being rushed, is often why coding style is horrific.

Mhmm.

I thought there was a section in the video about this? Perhaps it was another video I watched recently.

No, it's in this video, he talks about it for a few minutes at least.

Offline Arklon

  • Administrator
  • Hero Member
  • *****
  • Posts: 1267
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #23 on: October 14, 2018, 12:58:45 AM »
Comments should be written with the mindset of, "what would I forget about if I were to not look at this code until a year later?" I think sometimes even semi-obvious comments can be reasonable, like say labeling what if/else if/etc. branches are for, so you can digest the logic at a quick glance, as long as such comments are brief anyway.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Seven Ineffective Coding Habits of Many Programmers
« Reply #24 on: October 14, 2018, 11:02:54 AM »
Eh, maybe to some degree. Generally I only put assumptions the code makes in comments within the code itself. I do add comments ahead of functions... mostly it's a force of habit from the perspective of generating man pages using doxygen. Even still for the most part the comment is very brief (e.g., onMouseDown(MouseButton, int, int) doesn't really need complete documentation of every parameter and exactly what it does, so /* event handler for mouse down events */ suffices... and even then it's almost too much).

Anyway, like I said, I used to comment everything... I remember a book once providing the advice of first building pseudocode in comments and then fleshing out the code itself around the comments. I realized pretty quickly how terrible this advice is and have since switched to really only documenting assumptions the code is making (e.g., /* nullptr is never passed so it's not checked for here */) or why a particular choice was made by the programmer (e.g., /* using divide operator instead of a bitshift for clarity */). These are somewhat contrived examples but basically illustrate the point.