I wish more projects would start using this : http://editorconfig.org/
I don't care whatever the original author of a project used, as long as my editor does the same automatically when I contribute.
Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
11–20 of 22 posts
Re: Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
#12>> Should you use the tab button or five spaces when you're indenting source code? Five? What sort of freak uses five? And you should use the tab button, with your editor set up to insert four spaces instead of tab characters. This way display is consistent across editors, platforms etc etc I must say I'm surprised at the result for 'C' on there, as I've never worked with a C programmer that used tabs.
>I've never worked with a C programmer that used tabs.
cough linux kernel cough
Re: Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
#13>> Should you use the tab button or five spaces when you're indenting source code? Five? What sort of freak uses five? And you should use the tab button, with your editor set up to insert four spaces instead of tab characters. This way display is consistent across editors, platforms etc etc I must say I'm surprised at the result for 'C' on there, as I've never worked with a C programmer that used tabs.
'Ellemtel' uses 3 spaces.
Re: Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
#14>> Should you use the tab button or five spaces when you're indenting source code? Five? What sort of freak uses five? And you should use the tab button, with your editor set up to insert four spaces instead of tab characters. This way display is consistent across editors, platforms etc etc I must say I'm surprised at the result for 'C' on there, as I've never worked with a C programmer that used tabs.
>I've never worked with a C programmer that used tabs. cough linux kernel cough
Huh, guess so, just looked at the style guidelines.
I haven't done much with the kernel (nothing merged back upstream anyway), so I guess it never came up.
Re: Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
#15And let's assume most programmers don't changes their editors auto-indent default. How does this affect the result?
I just checked Webstorm which converts tabs to spaces so all my code is spaces but I only tabs. Go figure.
Re: Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
#16It's strange, that the white space in languages without "meaningful white space" has any impact after all.
Of course I like a blank line between blocks of more related functions, but I wonder why there is no standard for such things. Many text editors do the right step and auto-convert to your preferred spacing, but it's still strange there is no standard for it.
Re: Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
#17It would be interesting to see if there is a trend on the spaces / tabs per language statistics, and I would also be interested by the numbers of spaces per language.
e.g. I always use two spaces, but I mostly code in Ruby / JS / CoffeeScript. And that may influence my preference.
Re: Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
#18Earlier quoted context omitted.
LOL. Always found two a little too dense personally. And yeah, meaningful tab characters in Makefiles are a real sod...
I guess that would depend on the density of the language - I prefer 2 for clojure / common lisp and 4 for C and python. At the end, we're trying to optimize for readability, and the horizontal indentation needs to be more or less in harmony with how tight the code is vertically... for example, see this completely random and subjective selection from two of my projects: void consumeInput(gap * sudoku, inputQueue * q){…
Off topic, but could you explain the destructuring form you've used in your Clojure function? I've not seen destructuring with keywords in first position (in vectors, no less) before: is this something new for 1.9? I can't get it to work under 1.8.
What does it offer over the standard associative destructuring form:
(let [{auths :authentications, curr :current} identity]
...Re: Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
#19Earlier quoted context omitted.
I guess that would depend on the density of the language - I prefer 2 for clojure / common lisp and 4 for C and python. At the end, we're trying to optimize for readability, and the horizontal indentation needs to be more or less in harmony with how tight the code is vertically... for example, see this completely random and subjective selection from two of my projects: void consumeInput(gap * sudoku, inputQueue * q){…
Off topic, but could you explain the destructuring form you've used in your Clojure function? I've not seen destructuring with keywords in first position (in vectors, no less) before: is this something new for 1.9? I can't get it to work under 1.8. What does it offer over the standard associative destructuring form: (let [{auths :authentications, curr :current} identity] ...
Well it seems to work with 1.7. Try:
(let [[[:a a]
[:b b]] (vec {:a 1
:b 2})]
(println a b))
Re: Google Coder Analyzes a Billion Files to Find a Winner in Tabs vs. Spaces Debate
#20Earlier quoted context omitted.
Off topic, but could you explain the destructuring form you've used in your Clojure function? I've not seen destructuring with keywords in first position (in vectors, no less) before: is this something new for 1.9? I can't get it to work under 1.8. What does it offer over the standard associative destructuring form: (let [{auths :authentications, curr :current} identity] ...
Well it seems to work with 1.7. Try: (let [[[:a a] [:b b]] (vec {:a 1 :b 2})] (println a b)) But yeah, it's just an old and ugly hack from when I knew no better. It should look like your version.
You're right, it works under 1.7. But not under 1.8: I get an "Unsupported binding form" exception.
A bit of digging suggests it was an unwanted side effect of allowing destructuring of name-spaced keywords in maps, introduced in 1.5:
> CLJ-1318 ("Support destructuring maps with namespaced keywords") introduced two potentially undesired behaviours:
> [snip]
> 2. Keywords were allowed in any binding key positions. Keywords are converted to symbols (retaining namespace) and treated according to the rules of symbols in the rest of the destructuring logic. From what I understand the idea was to allow keywords only in map destructuring, but again the change change was effected for any binding key.
-- http://dev.clojure.org/jira/browse/CLJ-1778
1.8 removed keyword-first destructuring forms for vectors.