Beefy Boxes and Bandwidth Generously Provided by pair Networks Frank
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^3: On Coding Standards and Code Reviews

by puudeli (Pilgrim)
on Feb 19, 2009 at 08:21 UTC ( #744974=note: print w/ replies, xml ) Need Help??


in reply to Re^2: On Coding Standards and Code Reviews
in thread On Coding Standards and Code Reviews

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


Comment on Re^3: On Coding Standards and Code Reviews
Download Code
Re^4: On Coding Standards and Code Reviews
by eyepopslikeamosquito (Canon) on Feb 19, 2009 at 09:40 UTC

    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'm not sure allowing each developer to set their own indentation level works very well in teams doing pair programming.

      Of course you let the team decide the indentation scheme and then everybody sticks to it. There is no reason to allow chaos :-)

      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.

      Well, that is one way to see it but it feels too dogmatic for me. To achieve it, you would have to dictate coding standards and enforce them brutally.

      The code never looks the same (unless I have total control over it, which I rarely do) and people tend to write code differently using different formatting (opening braces, spaces in array indexing etc.) and some editors provide syntax high-lightning and other tools forcing the looks to be different. The style to aim for is the one that can be changed/converted to the desired format, no matter what scheme or tool was used.

      --
      seek $her, $from, $everywhere if exists $true{love};
Re^4: On Coding Standards and Code Reviews
by Mr. Muskrat (Abbot) on Feb 19, 2009 at 15:45 UTC

    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.

Re^4: On Coding Standards and Code Reviews
by JavaFan (Canon) on Feb 19, 2009 at 22:57 UTC
    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.

      You have a valid point (++ for that) but I still want to leave the choice to the persons responsible of the code. If a team chooses to use spaces it is fine with me. The result is still the thing I am most interested in. If the code is formatted in a way that keeps it maintainable and I can use a formatter when changes are required I am happy with it. ruzam said it nicely, formatter should be the only standard if a formatting standard must exist.

      Overall, in my list code formatting is not the most important coding standard. There are more important things to keep in mind and they are all related to design issues like data encapsulation, module/object/function re-usability and independence (allows unit testing of a single coherent set of functionality) and so on. I do not want to belittle formatting, but it can be automated making it less important.

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (7)
As of 2014-04-20 17:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls