Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I understand your frustration. However, I'll suggest that you use 8-space indentation with *spaces* not *tabs*. That way, regardless of my editor settings for tab width, I'll see that your style is 8-space indentation and (as a good contributor) can follow that easily. Whereas if my tab-width is set to 4 or 2, then I'll never know that you want 8 spaces and you're more likely to get something inconsistent back (particularly if I'm trying to line things up across multiple lines at something that *isn't* a

    • I understand your frustration. However, I'll suggest that you use 8-space indentation with *spaces* not *tabs*. That way, regardless of my editor settings for tab width, I'll see that your style is 8-space indentation and (as a good contributor) can follow that easily. Whereas if my tab-width is set to 4 or 2, then I'll never know that you want 8 spaces and you're more likely to get something inconsistent back (particularly if I'm trying to line things up across multiple lines at something that *isn't* a 8-space tab multiple.)

      But this is not a problem if you follow the simple rule that you use tabs only for the lefthand indenting. If you need to line things up over multiple lines somehow such that this would break, then do not use tabs, use spaces.

      • Yes, in an ideal world I would and so would everyone else. Unfortunately, it's not an ideal world and when multiple people contribute to something, it's possible that someone won't follow that guideline.

        My point was that using only spaces will (a) be more apparent to contributors that 8-space indentation is desired and (b) be more robust to fix when someone intentionally or inadvertently mixes tabs and spaces.

        • Yes, in an ideal world I would and so would everyone else. Unfortunately, it's not an ideal world and when multiple people contribute to something, it's possible that someone won't follow that guideline.

          How is that different from any other guidelines?

          My point was that using only spaces will (a) be more apparent to contributors that 8-space indentation is desired

          But I am saying it is NOT desired. TABBED indentation is desired, NOT 8-space indentation.

          and (b) be more robust to fix when someone intentionally or inadvertently mixes tabs and spaces.

          I've never had any problem converting tabs to spaces, it's pretty simple.

        • be more apparent to contributors that 8-space indentation is desired

          Why should they care? No one needs to know. As long as everyone sticks to the rule that tabs are for indentation and only tabs are for indentation, tab width is completely irrelevant. Which is the whole point of using tabs at all.

          • First, to clarify -- I mean that 8-character wide indentation is desired (by Alias in this case).

            As long as everyone sticks to the rule

            But they don't (or Alias wouldn't be so annoyed).

            My point about using spaces over tabs is that it will be more immediately obvious to anyone opening a file what the author's desired indention width is.

            You may not like it -- you may think "what an idiot, using 8-space indentation instead of tabs!" but at least you'll notice. Or, if you should happen to use tabs at w

            • If they don’t stick to tabs-for-indentation-only, what makes you think they’ll stick to any other rule? And how are violations of this rule much harder to fix than violations of other rules?

              If a contributor used the same formatting conventions as in the rest of the code, then it’s easy to fix their patch – mostly, down-convert everything to spaces first, then up-convert space runs at the start of the line**, then check whether that introduced any non-indentation tabs, which is easy

            • > My point about using spaces over tabs is that it will be more immediately obvious to anyone opening a file what the author's desired indention width is.

              Only if every author does it!

              If you use 8-spaces, and I use 8-character tabs, and I open up your code, I probably won't notice and just use tabs anyway.

              So know you'll still have spaces and tabs mixed...

              • And then when I get the patch or sync from subversion, I can s/\t/ /g and I'm done.

                • That should have been 8 spaces, but the HTML rendering compressed it, of course.

                  • (Here’s an   just for you. ;-) )

                    • Thanks. I'm spoiled by <code> on Perlmonks where it DWIW whereas here it just changes the font. <ecode> works here, but forces a new block instead of doing it inline.

    • Use tabs only at the very left of the line, and only to bring the line into proper indentation depth. If you need to move something further to the right (past its indentation depth) to line it up with something on the previous line, use spaces. In short:

      Tabs are for indentation. Spaces are for alignment.

      Use this simple rule and it won’t matter whose tabs are set at how many columns; there will be no inconsistencies, regardless.

      (This rule does break if you try to line things up verrtically across

  • I agree with the principle. The code owner decides the formatting. Of course, the contributors are free people also and can decide if they like the terms or not. I've got no problem matching somebody else's formatting in order to contribute, nor most of their code style. However, I'm personally not willing to expend extra effort to maintain compatibility with old perls, so I'd be liable to send in a contribution and say "Here's some work; hope you can use it" and respond to "Can you make it work with pe

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • Just use perltidy!
    • The problem with that approach is that if you check in a tidied file it wallops the diff. Yes you can argue that you should retidy it to group development standards, etc. but those are largely manual processes that get developers grumpy.

      Subversion has great pre-commit hooks, but the core problem is that you can't actually have it tidy the file and then check it in. And then you have to have your editor retidy to your specs.

      But hey, this can be done with wrappers around the svn binary right? Someone has

  • I agree totally.

    I also use 8-space tabs, and only for most lefthand indenting. It is not a problem!
    • When Perl Best Practices came out I was annoyed that it did not recommend tabs.

      I had a chance to chat to Damian at some point and I asked him why go for spaces and not tabs.

      He said that tabs WERE a better choice, but by encouraging tabs it emerged that it was just too tempting for developers in general to then use the tabs after the beginning of the line, which (obviously) breaks things.

      So on the balance of the two factors (what is strictly better, and bad behaviours that it encourages) the spaces option wa
      • Indeed, and indeed. I learned some of my tabbing practice from a codebase where tabs were used after indentation, such as to line up (in C) variable declarations' types and names. Took me a little while, many years ago, to get out of that (and unfortunately we still have a bunch of that lying around).

      • Hmm; I'm almost persuaded. I may start using tabs.

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • … is have tabstops expand or shrink to fit their contents [nickgravgaard.com]. In fact this would also make proportional fonts palatable for coding. Now if only editors actually supported all that… :-)