21–30 of 124 posts
This makes results completely useless, as files of people who really do not care will count for one side or another randomly.
[1] I say "probably" because even when I have written in Vala, C++, Ruby, Python, JavaScript, I have always relied on the IDE to automatically select the most common indentation in the project, so I never realize if I am using Tabs or Spaces since hitting the Tabulator key while using spaces will simply translate them to the correct indentation.
But in all seriousness, how often something is used isn't an indication of how good it is. Spaces are like cigarettes. Just don't start.
I've never really understood why you would use several characters (=spaces) for something that is semantically one indent. Can someone enlighten me? What are the advantages of spaces over tabs?
If you use spaces, you can format code, knowing it will look right on other people's machines. Perhaps a sufficiently organised bunch of programmers could edit a large code base such that it viewed fine with 2,4 or 8 character tabs, but is it worth the pain?
I've never really understood why you would use several characters (=spaces) for something that is semantically one indent. Can someone enlighten me? What are the advantages of spaces over tabs?
Not all editors are smart about tabs and spaces, and when the two start to mix things get really funky if everyone doesn't have the same "1 tab = x spaces" value set on their editor. For example: function_call(really_really_really_really_really_argument1, really_really_really_really_really_argument2) Say that this is supposed to be at one indent level. The beginning of both of those lines should contain only one tab,…
function(
really_really_really_really_really_long_argument1,
really_really_really_really_really_long_argument2,
really_really_really_really_really_long_argument3);After 20+ years of listening to the tabs-vs-spaces debate and considering all the legitimate points that both sides have, many have made the following observation and it's what resonates with me the most: In an ideal perfect world, _all_ of programmers and _all_ text editor tools would use tabs specifically for indentation and spaces specifically for alignment. But, we don't live in that perfectly coordinated world s…
My other personal feeling is that it's easy to auto-check we aren't using tabs (just search for tabs, and reject if any are found). Depending on how you choose to format, it can be arbitrarily hard to check tabs are being used correctly. For example, many people want to do some space indenting, such as: void my_function(int arg1, int arg2, int arg3) { It's (I believe) impossible for a language-agnostic tool to know t…
This let's me know if I left any trailing tabs/spaces before committing, align code better and while writing not while "refactoring".
git commit -am 'Whitespace formatting changes only'
No.
After 20+ years of listening to the tabs-vs-spaces debate and considering all the legitimate points that both sides have, many have made the following observation and it's what resonates with me the most: In an ideal perfect world, _all_ of programmers and _all_ text editor tools would use tabs specifically for indentation and spaces specifically for alignment. But, we don't live in that perfectly coordinated world s…
Unless you're using golang,in which case gofmt will correct you. Hence the overwhelming consensus of the go row for tabs.
After 20+ years of listening to the tabs-vs-spaces debate and considering all the legitimate points that both sides have, many have made the following observation and it's what resonates with me the most: In an ideal perfect world, _all_ of programmers and _all_ text editor tools would use tabs specifically for indentation and spaces specifically for alignment. But, we don't live in that perfectly coordinated world s…
Unless you're using golang,in which case gofmt will correct you. Hence the overwhelming consensus of the go row for tabs.
Earlier quoted context omitted.
def do_something( param1, param2, param3, param4 ): ... It's not that hard. Alignment is generally harmful - it's a maintenance burden which adds whitespace noise on diffs, which means more noise in code reviews. Not to mention how atrociously ugly it is when long variables/method names lead to 5+ lines with 60+ characters of indent for a single variable name per line.
Most diff programs have an "ignore whitespace" option. "whitespace noise on diffs" is pretty much a solved problem. You can even add '?w=1' to a Github URL to turn on the feature.
2. Those options are not perfect, they don't always work as expected
3. Those options are not turned on by default (because that would be INSANE)
4. Git's not the only VCS, much as I wish it were
5. Github's not the only Git web UI; that option is not available everywhere.
It's not a "solved problem". It's an artificial problem, that gets solved when you start consistently stripping trailing whitespaces on save and not realigning everything all the time.
Earlier quoted context omitted.
Not all editors are smart about tabs and spaces, and when the two start to mix things get really funky if everyone doesn't have the same "1 tab = x spaces" value set on their editor. For example: function_call(really_really_really_really_really_argument1, really_really_really_really_really_argument2) Say that this is supposed to be at one indent level. The beginning of both of those lines should contain only one tab,…
Your point is valid, that's why I write function( really_really_really_really_really_long_argument1, really_really_really_really_really_long_argument2, really_really_really_really_really_long_argument3);
