http://qs321.pair.com?node_id=847525


in reply to No Hard Tabs in Code

I'm a spaces person. Sharing code among folks who's editors have different ideas on how big a tab should be have cured me.

My current editor is set up to "Outdent" a line on Shift-Tab. Heck, I don't even need to have the cursor before the 1st printable character. This handles many of the OP's concerns.

I've also bound perltidy for easy access within my editor. That and a well formed .perltidyrc file do wonders for maintaining order in my source.

I have heard the occasional horror story about perltidy introducing bugs into code, but I've been using perltidy for quite some time on my own code, published obfuscations and published japhs (it really helps understand what these crazy folks are doing) with no ill effect. I do wonder what atrocities these story tellers were committing and what vintage of perltidy they were using....

Replies are listed 'Best First'.
Re^2: No Hard Tabs in Code
by Xiong (Hermit) on Jul 01, 2010 at 14:42 UTC

    Shift-Tab does different stuff in Geany. When cursor is within leading indentation, it subtracts a level; it does this correctly whether cursor starts at a tab stop or not. When cursor is somewhere after the first printable char, it just moves the cursor back to the previous stop; it doesn't alter the line at all.

    But if Shift-Tab caused little green worms to crawl out of the window, I wouldn't use hard tabs anymore. Lesson learned.

    - the lyf so short, the craft so long to lerne -
[reply]
Re^2: No Hard Tabs in Code
by Anonymous Monk on Nov 25, 2010 at 06:03 UTC

    I have two .perltidyrc files.

    One contains just this line: 

    -pbp

    [download]
    The other contains various heretical statements such as 
    -i=3   # Indent level is 3 cols
-et=3  # Use tabs for indents because I'm such a sociopath
-ci=3  # Continuation indent is 3 cols
-icb   # Make closing braces align with the body of their block

    [download]

    As I'm editing code, I'll run perltidy over it with my preference for formatting. Before checking code back in, I'll run perltidy with the Perl Best Practices formatting, run ./Build test and commit.

    I, too, draw a distinction between "indenting" and "alignment". I, too, program in languages other than Perl (such as Ruby, Python and PHP).

    I also edit using a proportional font (DejaVu Sans is my current favourite), which renders any attempts at "alignment" futile. I cannot stand the practice of sticking in extra spaces to make the '=' symbols line up.

    The perltidy tool lets me slip in under the radar of contemporary society.

[reply]
[d/l]
[select]

      Until you run into constructs that perltidy misformats. Then your coworkers will eventually wonder, every time they fix the use of & to override a prototype and then you touch unrelated code in the same source file, why the space gets re-inserted stupidly...

      Do you at least look at the differences you are introducing before you finish checking in? Probably not. Probably making merge conflicts significantly worse plenty of times as well.

      - tye        

[reply]
[d/l]

In Section Meditations