Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re: On Coding Standards and Code Reviews

by Tanktalus (Canon)
on Feb 19, 2009 at 05:57 UTC ( [id://744948]=note: print w/replies, xml ) Need Help??


in reply to On Coding Standards and Code Reviews

I guess it may be just me, but I'm curious as to why. Some of your suggestions/commandments are purely arbitrary, and I don't use that in a negative light as sometimes there is no best choice and consistency is more important, but I'm still curious as to why you chose that arbitrary rule over another similarly-weighted controversial rule.

Just to pick on the first one that popped out, using spaces over tabs. Don't get me wrong, I agree with it, but I know it's contentious, and would prefer to see something that expanded on why. This goes doubly, if not more, if you're going to need to not just defend your rules against peers in your organisation, but against every single new hire for the rest of your tenure there. It also allows the rules to be properly challenged if, for example, the significance of your decision is reduced.

As an example, continuing to pick on the spaces vs tabs, perhaps it is desirable for each developer to use the tools they're most comfortable with. That may mean some of your developers using eclipse, others using emacs, others using vi, and the odd wacko using notepad, as long as each is highly productive. But then, perhaps your management (either personnel or technical) decides for some reason to standardise on an environment - whether that's MS Visual Studio, Eclipse, or Komodo. Now maybe the reason for spaces goes away, and it can be revisited. But without a continued, on-going understanding of the reasoning, your rules become unchallengeable shackles or cargo cult, possibly long outliving their usefulness.

I know you have lots of links, but, without going through each one manually, it's difficult to know (in general) which link defends which rule. Some are obvious, but not all, so you should still have as direct of links as possible for most items.

My second suggestion would be to store the whole thing in a corporate wiki where others can add their reasons for (or possibly even against) each dictum, making it (hopefully) feel less like dictum, and more like group selection, and thus easier to self-enforce. It also would help keep the document living which helps it stay in use, as well as keeps it available for challenge.

Replies are listed 'Best First'.
Re^2: On Coding Standards and Code Reviews
by eyepopslikeamosquito (Archbishop) on Feb 19, 2009 at 06:51 UTC

    Just to pick on the first one that popped out, using spaces over tabs. Don't get me wrong, I agree with it, but I know it's contentious, and would prefer to see something that expanded on why.
    This is discussed in Perl Best Practices, page 20, "Indent with spaces, not tabs". Quoting Conway:
    Tabs are a bad choice for indenting code, even if you set your editor's tabspacing to four columns. Tabs do not appear the same when printed on different output devices, or pasted into a word-processor document, or even just viewed in someone else's differently tabspaced editor.
    Not being an "expert book author", many folks here won't listen to me, so I prefer to point them to a well-respected reference, such as PBP.

    For some of these layout rules (e.g. brace placement), we already fought a war some years ago and I don't want to reopen old wounds. With over ten million lines of existing code, it doesn't seem worthwhile to change longstanding company code layout conventions.

    I know you have lots of links, but, without going through each one manually, it's difficult to know (in general) which link defends which rule. Some are obvious, but not all, so you should still have as direct of links as possible for most items.
    Agreed. I'll try to provide a reference/s for each rule. I expect that will prove to be important for some folks here who may object to blindly accepting a rule without a supporting reference.

      Tabs are a bad choice for indenting code, even if you set your editor's tabspacing to four columns. Tabs do not appear the same when printed on different output devices, or pasted into a word-processor document, or even just viewed in someone else's differently tabspaced editor.

      Having lot of respect for Damian Conway I would like to point out that almost all useful editors allow you to define the tab length. Be it 2, 4 or 8 spaces. Using tabs allows every developer to have their own indentation level by defining the tab width in their preferred editor/pager/viewer settings. Using spaces forces one indentation scheme (and forcing people is a bad thing). I always tell people who are arguing over indentation that whether you choose to use tabs or spaces you must use it systematically. Do not mix tabs with spaces.

      I use spaces my self (spaces are what I am accustomed to), but I do not despise tabs.

      --
      seek $her, $from, $everywhere if exists $true{love};

        I'm not sure allowing each developer to set their own indentation level works very well in teams doing pair programming. FWIW, Michael G Schwern holds the same view as Damian:

        Here's all I have to say about tabs. I expect the source to look the same no matter whose editor, pager, printer or utility I run it through. Literal tabs violate this. The end.
        I also notice that the Parrot coding standard mandates that "Indentation must consist only of spaces".

        Though I agree with Conway and Schwern on this, the main reason I chose spaces over TABs is that is we currently do that (mostly), and I don't want to change over a million lines of legacy code. :-)

        I would like to point out that almost all useful editors allow you to define the tab length. Be it 2, 4 or 8 spaces.

        I would like to point out that those very same editors have a setting that when enabled will automatically converts tabs into a user-definable number of spaces.

        Having lot of respect for Damian Conway I would like to point out that almost all useful editors allow you to define the tab length. Be it 2, 4 or 8 spaces.
        And that's the one and only the reason why tabs are evil. Tabs are fine if they act the same in every editor.

        Suppose you have a 80-column coding standard. You have a 3 character indent as standard. You set your tab width to 3 spaces because you indent with tabs, and you have a subroutine containing a loop, and an if statement in that loop. Inside the then block, you have a 65 character line. In your editor, the line ends in column 74, well within the boundaries.

        Now the next person never uses tabs, and uses an editor (s)he didn't customize to your habits. Hence, the tabwidth will be at 8. Now your 65 character statement ends at column 89, violating the coding standard.

        That's why tabs are evil. Because you do not know how where the tabstops of the next person will be. Spaces are predictable. Tabs aren't.

      For Pete's sake people it's tabs and spaces!

      How many hours of productive time has been wasted in meetings arguing the pros and cons of each? Does Perl care whether you've used spaces over tabs or tabs over spaces? We've already agreed that most editors can seamlessly convert between tabs and spaces of any desired indent size. The pettiness of it just blows my mind.

      Here's a standard: forget standards. Use Perltidy.

      A large portion (if not all) of the coding standards listed here could be configured into Perltidy. If every piece of code passed/used/saved anywhere in the company is enforced through Perltidy, then all code will conform to a single layout standard. The coders don't need standards, they can code to what ever style they feel comfortable with. After a pass through Perltidy everybody's code will conform to the same single standard.

      In time coders will make an effort to conform to that same standard that they've been immersed in because it's just easier to adjust one's personal style choices than to buck miles of existing code. But even if they don't come around, who cares? In the end the code will come out formatted to standards regardless, and all the time that would have been wasted arguing over standards can be put to better use getting actual work done.

      end grump

        You're right. It's tabs and spaces. That's exactly why it's important to write it down (complete with pros/cons and links), and end the debate. That's why I think it's a good idea to put it in the rules - so you don't keep going around and around on it. I'm not convinced there is an obviously-right answer (i.e., one that you'll get everyone to facepalm and say, "of course, that's right!"), which means you'll always get pushback. But if it's written down, explanation given, you'll probably at least find acceptance from those who disagree, and can move on to being actually productive.

        Of course, running your code through perltidy before checking it in (or, better yet, having the VCS running the code through whichever tidy tool is appropriate) is even better. But, even then, you'll have to explain why your tidy tools are doing this, so that those who disagree with the formatting option can be, well, silenced, if not assimilated. Otherwise, every time you hire a new person, you'll have to explain it all over again, even if it's automated via perltidy or whatever.

        Here's a standard: forget standards.

        ++!

        On the side node, I wish Perltidy would be able to convert between the horribleCamelCase and well_defined_underscore_names too.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://744948]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (4)
As of 2024-03-29 11:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found