Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re^4: My coding guidelines

by emazep (Priest)
on Sep 08, 2005 at 18:04 UTC ( #490286=note: print w/replies, xml ) Need Help??

in reply to Re^3: My coding guidelines
in thread My coding guidelines

You will virtually always find situations where you can't indent properly with just tabs alone. Which means that if you work with tabs set at different size the code turns becomes very difficult to deal with.
This could be a problem, but it shouldn't be difficult to eliminate it. In order to do so, even if you use a mix of spaces and tabs to indent (or rather to align things vertically) just always use tabs to indent (that is, to align vertically the left margin of the lines), and reserve the use of spaces to align vertically only the things past the left margin (in the middle of a line, so to say) such as the => symbol in a hash. In other words, never use spaces to align the left margin and reserve their use only to align the things inside a line. Here is an example:
my %a_hash = ( <TAB> very_very_long_key => 1, <TAB> k2 <SPACES> => 2, <TAB> another_k <SPACES> => 3 );
I've personally used (and spread) this convention for years (mainly with languages different from Perl though) and never had a single problem or complaint.
The only problem I can see happens if you want to use a fancier alignment like this:
my %a_hash = ( very_very_long_key => 1, k2 => 2, another_k => 3 );
but frankly I would avoid it (though some people seem to like it).
IMO forcing people to use your indentation is minimal issue
This is true as long as everyone religiously adopt the same, sensible number of spaces (4 could be OK, but not necessarily, see later), but I've seen so many times people who love to indent with just 2 spaces or even with a single space. As for the 4-spaces convention, not everyone agree: for example both the Linux kernel and the Gnome coders recommend to use 8-spaces (tabs) for indentation.

Thanks to their portability, tabs are IMO the only way to to settle this controversy and make everyone happy.


Replies are listed 'Best First'.
Re^5: My coding guidelines
by itub (Priest) on Sep 08, 2005 at 19:20 UTC
    The best solution to this controversy is to use perltidy. Just filter that nasty code through perltidy to get your preferred indentation, brace location, else-cuddledness, etc. If you are working in a team project, have the team define a standard set of perltidy options that are to be used before checking the code in. It can be automated as part of the check-in process so that you don't have to worry about it.
      The best solution to this controversy is to use perltidy.
      This is a good advice, except that then again you have to decide if you want to use tabs or spaces for indentation, when it comes to tell perltidy about it ;-) (through the options -et and/or -t).

      I'm realizing that people are scared about tabs (even the perltidy docs recommend against it) because they think that problems may arise if not everyone is using the same number of spaces to display tabs in their editors, while few seem to realize that permitting each user to display the tabs the way she prefer is just the great advantage here.

      Tabs will let the user to freely decide how many spaces to display for indentation, at the sime time granting the other users the same freedom.



        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
Re^5: My coding guidelines
by demerphq (Chancellor) on Sep 09, 2005 at 07:31 UTC

    In my experience the problem comes when people use editors that use tabs set at 8 spaces, and indentation rules of 4 spaces, with the editor autobundling 8 spaces into a tab when it can. This is a common editor set up IME, and just positively sucks when you change the size of tabs. And that was my point, using tabs you end up in debates about crap like this, using spaces you never do.

    Theres another aspect of Tabs that I havent seen mentioned, and that is their impact on a diff. One thing I find particularly annoying is that tabs in your code can lead to diff saying a line has changed but when you look at the line it looks identical. Its only when you notice that somone has accidentally stuck a space in front of a tab that you realize why diff is telling you what it is. IMO avoiding such scenarios is a good reason in itself to avoid tabs. Just like IMO its a good reason to avoid trailing whitespace.

    Anyway, this is one of those debates that I believe has proved intractable. There will always be stalwarts out there for one side or another. All i can say is that the pain of dealing with multiple tab sizes, and even tabs in general, has made me adopt a policy of: no tabs in source code, no trailing whitespace in source code.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://490286]
[Tanktalus]: 1nickt: how's cbstream been for you lately? :D

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2017-10-17 17:24 GMT
Find Nodes?
    Voting Booth?
    My fridge is mostly full of:

    Results (235 votes). Check out past polls.