March 17, 2012 at 7:22 pm
Comments posted to this topic are about the item Tabs or Spaces
March 18, 2012 at 11:37 am
I propose the following amendment to "... only programming project with no disagreement whatsoever on code formatting is the one you work on alone", to wit:
"... only programming project with no disagreement whatsoever on code formatting is the one you work on alone, or when everyone viewing the code runs it through a code beautifier first".
My answer to tabs vs. spaces, case convention, and pre vs post commas is always to let a computer do tedious, menial, purely rules based work - use a SQL beautifier/formatter. If someone else doesn't like your settings, they can use _their_ settings. None of that matters to the SQL parsing engine, so why should it matter to us?
There's a few out there, of which SQLInform[/url] is a reasonable one, though it doesn't have as many options for list indentation as I'd like. It does handle at least some of the tabs vs. spaces conversions, to however many spaces per tab you prefer!
March 18, 2012 at 10:30 pm
Perhaps the major reason I hate tabs in code is that tabs are not interpreted in the same way on all systems - some may have 4 spaces, others may have 7. This leads to a perfectly aligned and readable code on one machine, but mis-aligned code on another machine.
Another reason why I am against tabs is that result in the cursor jumping all over the place when scrolling up or down using the keyboard to find where an "END" exists for a particular "IF".
I always insist that my team has the "replace tabs with spaces" switch in SSMS options checked and also run code through the "beautifer" option of "Untabify selection".
In my humble opinion, there should be a consistent set of coding aesthetic standards that should be enforced by default (and result in warnings) by Visual Studio and associated tools.
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
March 18, 2012 at 10:43 pm
I would tend to lean on the side of preferring tabs to spaces. I have worked in some environments where tabs would retain spaces like you mention but everybody had their own personal preference as to how many spaces represented a tab. The sql people typically used 4 spaces and the Delphi people typically used 8 spaces. It made all the stored procs so horribly formatted that we actually created a function (as a joke) to assign a random number of spaces to indent each line.
I can't imagine actually having an argument about it because I really don't think there is the one right way to go here. For me there plenty of other things to have arguments about than the differences between tabs and spaces.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
March 18, 2012 at 11:53 pm
I will vote for tabs. Why? Just because I am lazy and using the arrow key to jump 4 spaces makes me smile. Our standards include the setup of the development environment. So tabs never cause ugly displays, and so I like it. I will retire in this company, so I do not have to worry about maintaining Steve's code someday. 😀
5ilverFox
Consulting DBA / Developer
South Africa
March 19, 2012 at 2:17 am
My Vote is for Spaces.
As previously mentioned there is no consistency in the interpretation of Tabs. I've seen 2, 4 & 8 Spaces.
Spaces are portable whereas Tabs are IDE specific.
I personally go for 2 Spaces mainly because I prefer to see all of my Code on one Screen without having to scroll left & right all of the time.
David
March 19, 2012 at 2:25 am
I vote for tabs. They can be extremely rapidly shown as 3, 4, 7... spaces by configuration and they can be converted to spaces if needed.
As I'm minority, I have my Visual Studio set to spaces.
March 19, 2012 at 2:32 am
There's no inconsistency in formatting using tabs provided you always use them--whether the code gets indented 4 or 8 spaces with a tab is largely irrelevant to its readability. Having said that, I prefer to use spaces simply because I can use fewer of them--I think a 2-space indent is ample, and if you use more than that (or use tabs) then you can end up having to scroll right to read the code in some cases!
Of course, these days it's almost a moot point because pretty much any competent code editor will have the capability of automatically indenting lines to suit your preferences.
March 19, 2012 at 2:33 am
I prefer spaces simply for the main reason that T-SQL code is easier portable and readable between SSMS and BIDS.
BIDS by default uses 8 spaces for a tab where SSMS is configurable. SSMS has a big screen for code review, BIDS by default has a tiny window.
Tabs in BIDS can make the code disappear right out of the window. This then means extra efforts to enlarge the window, after review (and fix) back to default size and just simply more clicks than I want to count. All of this can be achieved with even more key strokes.
My main pet pieve is simply lazy developers who just don't care to follow one style and just mix and match then complain about the coding standards of others.
March 19, 2012 at 3:50 am
I vote for tabs - less key strokes 🙂
March 19, 2012 at 4:22 am
Tabs - you can post hoc indent or outdent blocks more easily.
March 19, 2012 at 5:45 am
Tabs all the way.
March 19, 2012 at 5:46 am
I agree with call.copse. Tabs all the way
Although I did learn the hard way not to tab after # and space in the powershell ISE(Autocomplete failed and the ISE crashed on me. Had to add the space since hitting tab after # doesn't do anything)
March 19, 2012 at 6:48 am
What makes this even worse is when you use universal source control.
The quickest way to mess up the spaces and tabs in our SQL source is when we extract it and check it into source control.
When you pull the SQL scripts back out of source control all the tabs and spacing are off. The code still works, but readability is terrible.
This is mostly caused by code that was written with Tabs set to 3 spaces instead of 5.
March 19, 2012 at 7:02 am
I have SSMS set to replace tabs with spaces. That way I use a tab to indent but it actually uses spaces.
If I need to change an indent on a block of code I simply highlight the block and use tab or shift tab depend on which direct it needs to go.
Viewing 15 posts - 1 through 15 (of 49 total)
You must be logged in to reply to this topic. Login to reply