5 ms·

Thread's gotten too deep and wide to reply to everyone, so I'd like to vent right here at the top... We have these machines that are meant to take the tedium o

by delinka 13y ago

Thread's gotten too deep and wide to reply to everyone, so I'd like to vent right here at the top... We have these machines that are meant to take the tedium out of our lives, let's USE THEM. Why do we not have tools that format things they way I like them? Who cares how the other team members like it? They can use the tool, too. Who cares how it's stored in your VCS? The tool should just be part of the workflow and format spaces/tabs the way I want them and maybe revert to a canonical format for committing to the repo. Personally, I prefer tabs. I read code best when it's indented four spaces. But John wants to use two spaces in this code. And Ralph likes three. Holy Hell, don't make me wade through someone else's preferences to understand this codebase! Use tabs and people can set them the way they want. Yes, tabs are broken in many places (e.g. Objective-C methods can get so verbose that they need to wrap; convention is to wrap and align the colons; tabbing as far as possible and then spacing to fill breaks things when Ralph formats his tabs to three spaces; in this case, there is indeed a solution: tab to the start of the original line of code, and space to format from there ... but then the IDE has ideas of its own about what should be spaces and what should be tabs...) Maybe you can read that code with only two spaces of indent, but I can't. I'm gonna need that reformatted to put a larger visual separation between scope changes or whatever required the indention. Rather than have this debate, a tool should be forged.

gbog 13y ago
Disagree. Readability is not about 4 or 2 spaces, it is about strongly enforced convention that makes these typographic details literally disappear from the eyes of the readers. This effect is very noticeable in book publishing: if you ever notice the typography, the typographer failed at his task. It is the same in code, just file the rules and it will become your preferred guideline in no time. And repeated experiences everywhere point to the fact that code text is already very hard to manage, very sensitive to alterations, misreading, etc. I'd rather remove layers and tools than add more. Edit: obviously, readability is ask about convention when they are within the realm of sane acceptable conventions. And by everywhere I mean in teams where the loc count is above a few thousands.
- mden 13y ago
  Disagree with your disagree. There is a difference between the actual code and how the code is styled. It makes sense to have conventions on how to format a for statement but not where to add brackets - making them be on the same line or on their own line makes little difference to noticing bugs and is purely a stylistic preference.
  - gbog 13y ago
    So you mean that the where-the-brackets guidelines found in core FOSS mega-projects, big corps like Google, down to many github personal projects having their own "please follow the guides" in the readme, all of them are misguided, useless, wrong and even, let'y say it, plain stupid? I, on my side, claim that guidelines are there for a reason, and should be followed.
taude 13y ago
This looks at it only from the context of the single dev's machine. I care more about the consistency of the source code that's checked into the repository and not getting false file diffs based on white space differences, and other formatting discrepancies. And for some reason, this seems harder than it should be. I'd like to see a diff tool designed around this.
- mden 13y ago
  That wouldn't be hard at all. All you need to do is assign a default style and create the diffs in that style. The hard part is creating a tool that can change between styles. Such a tool would need to be made for every language separately which is a pain. I've been wanting to try something like this for years but have never built up the courage.
  - nfoz 13y ago
    This is part of the purpose of lint tools, and they exist for many languages. e.g. http://www.jslint.com/ http://www.jslint.com/
    - mden 13y ago
      Sorry, I think I misunderstood the comment I replied to. I thought he was saying it would be hard to do diffs if people restylized each file to their liking.
- deleted 13y ago
  [deleted]
subsection1h 13y ago
> Use tabs and people can set them the way they want. If members of a team set tabs the way they want, how do they limit line lengths to 80 columns, which is a requirement that's specified in the Linux kernel coding style that was linked to in the comment you replied to?
- gcb1 13y ago
  not an issue. by assuming it is two spaces. it is still better to have to switch to 2 tabwidth before committing to check line length then to be forced to use 2 spaces forever.
  - philjackson 13y ago
    How about lining things up? Take a long function call where you want to wrap the params: hello( world, solarsytem, universe ... ); You can't if you just use tabs - you would have to mix tabs and spaces.
    - Pxtl 13y ago
      Use hello( world, solarsytem, universe ); which doesn't require perfect line-up with the first entry, and is still clear to the reader what's going on.
      - MikeTLive 13y ago
        this is how i code. 1st pass: func( ); 2nd pass: put in the args. this ensures the closing paren immediately and makes it possible to comment out things that are inside the parens.
    - zobzu 13y ago
      so thats the reason why people are set on using spaces? man :(
lmm 13y ago
> Yes, tabs are broken in many places (e.g. Objective-C methods can get so verbose that they need to wrap; convention is to wrap and align the colons; tabbing as far as possible and then spacing to fill breaks things when Ralph formats his tabs to three spaces; in this case, there is indeed a solution: tab to the start of the original line of code, and space to format from there ... but then the IDE has ideas of its own about what should be spaces and what should be tabs...) Which is the problem. If you think it's possible to make a tool to solve this, great - do it, I'll happily adopt your tool as a precommit hook and use tabs to indent everything (or go on using spaces - your tool would turn them into tabs, right?) But given that this problem has existed since the '70s and no-one has solved it, I'm inclined to think it's impossible. So I'll use spaces in the VCS, which means agreeing an indent width so that our diffs make sense (and I don't really care whether that's two or four, but it does need to be defined and adhered to across the team).

by delinka 13y ago

gbog 13y ago

Disagree. Readability is not about 4 or 2 spaces, it is about strongly enforced convention that makes these typographic details literally disappear from the eyes of the readers. This effect is very noticeable in book publishing: if you ever notice the typography, the typographer failed at his task. It is the same in code, just file the rules and it will become your preferred guideline in no time. And repeated experiences everywhere point to the fact that code text is already very hard to manage, very sensitive to alterations, misreading, etc. I'd rather remove layers and tools than add more. Edit: obviously, readability is ask about convention when they are within the realm of sane acceptable conventions. And by everywhere I mean in teams where the loc count is above a few thousands.

mden 13y ago
Disagree with your disagree. There is a difference between the actual code and how the code is styled. It makes sense to have conventions on how to format a for statement but not where to add brackets - making them be on the same line or on their own line makes little difference to noticing bugs and is purely a stylistic preference.
- gbog 13y ago
  So you mean that the where-the-brackets guidelines found in core FOSS mega-projects, big corps like Google, down to many github personal projects having their own "please follow the guides" in the readme, all of them are misguided, useless, wrong and even, let'y say it, plain stupid? I, on my side, claim that guidelines are there for a reason, and should be followed.

taude 13y ago

This looks at it only from the context of the single dev's machine. I care more about the consistency of the source code that's checked into the repository and not getting false file diffs based on white space differences, and other formatting discrepancies. And for some reason, this seems harder than it should be. I'd like to see a diff tool designed around this.

mden 13y ago
That wouldn't be hard at all. All you need to do is assign a default style and create the diffs in that style. The hard part is creating a tool that can change between styles. Such a tool would need to be made for every language separately which is a pain. I've been wanting to try something like this for years but have never built up the courage.
- nfoz 13y ago
  This is part of the purpose of lint tools, and they exist for many languages. e.g. http://www.jslint.com/ http://www.jslint.com/
  - mden 13y ago
    Sorry, I think I misunderstood the comment I replied to. I thought he was saying it would be hard to do diffs if people restylized each file to their liking.
deleted 13y ago
[deleted]

subsection1h 13y ago

> Use tabs and people can set them the way they want. If members of a team set tabs the way they want, how do they limit line lengths to 80 columns, which is a requirement that's specified in the Linux kernel coding style that was linked to in the comment you replied to?

gcb1 13y ago
not an issue. by assuming it is two spaces. it is still better to have to switch to 2 tabwidth before committing to check line length then to be forced to use 2 spaces forever.
- philjackson 13y ago
  How about lining things up? Take a long function call where you want to wrap the params: hello( world, solarsytem, universe ... ); You can't if you just use tabs - you would have to mix tabs and spaces.
  - Pxtl 13y ago
    Use hello( world, solarsytem, universe ); which doesn't require perfect line-up with the first entry, and is still clear to the reader what's going on.
    - MikeTLive 13y ago
      this is how i code. 1st pass: func( ); 2nd pass: put in the args. this ensures the closing paren immediately and makes it possible to comment out things that are inside the parens.
  - zobzu 13y ago
    so thats the reason why people are set on using spaces? man :(

lmm 13y ago

> Yes, tabs are broken in many places (e.g. Objective-C methods can get so verbose that they need to wrap; convention is to wrap and align the colons; tabbing as far as possible and then spacing to fill breaks things when Ralph formats his tabs to three spaces; in this case, there is indeed a solution: tab to the start of the original line of code, and space to format from there ... but then the IDE has ideas of its own about what should be spaces and what should be tabs...) Which is the problem. If you think it's possible to make a tool to solve this, great - do it, I'll happily adopt your tool as a precommit hook and use tabs to indent everything (or go on using spaces - your tool would turn them into tabs, right?) But given that this problem has existed since the '70s and no-one has solved it, I'm inclined to think it's impossible. So I'll use spaces in the VCS, which means agreeing an indent width so that our diffs make sense (and I don't really care whether that's two or four, but it does need to be defined and adhered to across the team).