InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 23 May 2013 14:03:19 GMT20http://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]Nadrek (7/1/2010)[/b][hr]And once the entire team has it, there's no longer as much reason for everyone to follow the same standards anymore; if you don't like the code, load it up and let your software re-format it to your personal standard. Everyone else can do the same thing when it's their time to view that piece of code.[/quote]I've used a number of the auto-format tools over the years. Some are quite good.I've found that they lay out the code nicely about 98% of the time.Sometimes it's important to break the standard layout rules to [b]improve[/b] clarity. :-DI haven't found an auto-formatting tool that would allow me to say "don't touch the formatting on this section right here, it's exactly the way it needs to be".Thu, 01 Jul 2010 08:53:40 GMTdavid_wendelkenhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]niall.baird (6/30/2010)[/b][hr]Ah yes, but you can set sql refactor up to format however you like. Mine is set to leading commas, 'on' clauses on a separate line, 2 spaces indent etc etc.(and if the place I work at wasn't so slow in getting approvals for purchase orders, the entire team here would be using it!!!!)[/quote]And once the entire team has it, there's no longer as much reason for everyone to follow the same standards anymore; if you don't like the code, load it up and let your software re-format it to your personal standard. Everyone else can do the same thing when it's their time to view that piece of code.Thu, 01 Jul 2010 07:20:49 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]niall.baird (6/30/2010)[/b][hr]I personally prefer leading commas, as they're much easier to see, especially when you line them all up, but in response to Jeff, while you're correct in that if you comment out one line, its the same amount of effort whether you use leading or trailing commas, if you're doing a little more than just commenting out one line, ie comment out one line, add another line etc, it is much easier to see where you've missed a comma if you use the leading ones.[/quote]Understood but, again, personal opinion. Admittedly, I'm also a bit of an odd duck. I'll put all mathematical operators at the beginning of a line and punctuation at the end of the line. Hmmm... maybe not so odd, though. :-DWed, 30 Jun 2010 21:25:07 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxAh yes, but you can set sql refactor up to format however you like. Mine is set to leading commas, 'on' clauses on a separate line, 2 spaces indent etc etc.(and if the place I work at wasn't so slow in getting approvals for purchase orders, the entire team here would be using it!!!!)Wed, 30 Jun 2010 16:25:04 GMTniall.bairdhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxStandards... that's why I love formatting tools: everyone with the same formatting standards, like it or not.BEGIN ADWe use SQLRefactor and we're very happy with it. I've seen around other tools that do a very good job at formatting and allow much more options that SQLRefactor, but more options can mean different standards, so a limited set of options is welcome.END AD:-)Wed, 30 Jun 2010 16:21:17 GMTspaghettidbahttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]Jeff Moden (6/30/2010)[/b][hr][quote][b]david_wendelken (6/30/2010)[/b][hr]It's also easier to comment out a line starting with a comma when debugging.[/quote]Actually, it's not. It's only easier to comment out the last line with leading commas. If you use trailing commas, its easier to comment out the first line. Either way, the intermediate lines require the same amount of effort to comment out.[/quote]I agree with this. same effort.For me, I usually know 1 or 2 fields when I'm working on something. Don't always know which ones I want to add later, or take out for testing. Since I often remove the last line, I use leading commas.It's 6 of one, but your shop should agree on a standard.Wed, 30 Jun 2010 16:15:13 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxI personally prefer leading commas, as they're much easier to see, especially when you line them all up, but in response to Jeff, while you're correct in that if you comment out one line, its the same amount of effort whether you use leading or trailing commas, if you're doing a little more than just commenting out one line, ie comment out one line, add another line etc, it is much easier to see where you've missed a comma if you use the leading ones.Wed, 30 Jun 2010 16:12:58 GMTniall.bairdhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]Jeff Moden (6/30/2010)[/b][hr][quote][b]david_wendelken (6/30/2010)[/b][hr]It's also easier to comment out a line starting with a comma when debugging.[/quote]Actually, it's not. It's only easier to comment out the last line with leading commas. If you use trailing commas, its easier to comment out the first line. Either way, the intermediate lines require the same amount of effort to comment out.[/quote]I think it's just a matter of personal preferences.I prefer trailing commas, but it's just my way of seeing things. I think it's more like the way I would write a sentence in plain English (Italian?).I like to think that my code reads like spoken language.Wed, 30 Jun 2010 16:02:25 GMTspaghettidbahttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]david_wendelken (6/30/2010)[/b][hr]It's also easier to comment out a line starting with a comma when debugging.[/quote]Actually, it's not. It's only easier to comment out the last line with leading commas. If you use trailing commas, its easier to comment out the first line. Either way, the intermediate lines require the same amount of effort to comment out.Wed, 30 Jun 2010 15:41:36 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[font="Courier New"]This is in the format used in an earlier post:[code="sql"]select a.COLUMN_NAME_1, b.COLUMN_NAME_2, b.COL_NAME_3, b.COLUMN_4, b.COLUMN_NM_5, b.COLUMN_NAME_6from TABLE_1 a join TABLE_2 b on a.TABLE_1_ID = b.TABLE_1_ID and a.TABLE_1_ID2 = b.TABLE_1_ID2order by a.COLUMN_NAME_1, b.COLUMN_4, b.COLUMN_NM_5, b.COLUMN_NAME_6[/code]I prefer this format:[code="sql"]select a.COLUMN_NAME_1 ,b.COLUMN_NAME_2 ,b.COL_NAME_3 ,b.COLUMN_4 ,b.COLUMN_NM_5 ,b.COLUMN_NAME_6from TABLE_1 ajoin TABLE_2 b on a.TABLE_1_ID = b.TABLE_1_ID and a.TABLE_1_ID2 = b.TABLE_1_ID2order by a.COLUMN_NAME_1 ,b.COLUMN_4 ,b.COLUMN_NM_5 ,b.COLUMN_NAME_6[/code][/font]From an editing point of view, the commas line up vertically in each section. I don't have to scan multiple lines to figure out which line is missing the comma. It's also easier to comment out a line starting with a comma when debugging.Ands/Ors go to the front fo the line instead of the end of the line, for the same reasons. In addition, one is much less likely to mix ands/ors by mistake if they all line up vertically. Nested ands/ors are parenthesized and vertically aligned at their respective nesting levels.Wed, 30 Jun 2010 15:00:01 GMTdavid_wendelkenhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]niall.baird (6/23/2010)[/b][hr]Commenting:I like to see a comment block/change register at the top of each stored proc/function, something like[code]/* ************************************Name: pu_mytablePurpose: Updates dbo.MyTable with values from dbo.MyOtherTableDate Version Author Description***********************************1/1/2010 1.0 Great Coder Created2/1/2010 1.1 Great Coder Removed cursor, changed to set based update************************************ */[/code]but within the code, I like to see explanations before something funky - I don't believe its necessary to comment where something is blatently obvious.I also like to have my internal comments using 'single line' commenting (--) rather than block commenting (/* */)Also, any time you make a change, mark it with the version number!!!!![/quote]The structure of your commenting header is very similar to the type I use, but I always enter comment dates in YYYY/MM/DD format, so I can more easily search text in scripted objects using a regular expression tool.Thu, 24 Jun 2010 15:47:13 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxThat's nice. We often think about versioning our office documents and client program code this way but not our T-SQL procs. I comment in-line a lot but a version header might make it easier to get started looking at it. Isn't there documentation software that helps you do this?For comments I start with -- but a soon as it gets to be longer than a line or 2 I switch to /* */.KenThu, 24 Jun 2010 14:02:14 GMTken.trockhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxCommenting:I like to see a comment block/change register at the top of each stored proc/function, something like[code]/* ************************************Name: pu_mytablePurpose: Updates dbo.MyTable with values from dbo.MyOtherTableDate Version Author Description***********************************1/1/2010 1.0 Great Coder Created2/1/2010 1.1 Great Coder Removed cursor, changed to set based update************************************ */[/code]but within the code, I like to see explanations before something funky - I don't believe its necessary to comment where something is blatently obvious.I also like to have my internal comments using 'single line' commenting (--) rather than block commenting (/* */)Also, any time you make a change, mark it with the version number!!!!!Wed, 23 Jun 2010 16:04:15 GMTniall.bairdhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxWhere do I begin? The question is should we make our code readable? This is a no-brainer. YES! As a professional we have a responsibility to help the company run efficiently. Unreadable code doesn't accomplish that goal at all. In fact if it is unreadable the author may not be able to read it either!Someone mentioned pride in ones work--They're absolutely correct. If you happen to work for another techy, you will be caught and brought in! At least if they're up to speed. If you don't, how would you expect to make 'manager' with sloppy work?So much more to say, but the words all repeat the same answer. Of course code must be readable. LarryWed, 23 Jun 2010 14:35:43 GMTlbechdol-1117717http://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxI have been working with SQL Server for about 10 years. I have been in a SQL Server specialized job for about 6 months. I have refined my coding style substantially over the last 6 months. Things that I did occasionally did not really bother me, now I would never consider doing some of these things because I have seen issues in doing things that way when doing it daily. I also remember disliking a number of things that I do regularly now because I have seen the wisdom in that style.Much of good formatting is learned from seeing what others do, and recognizing why that is a good practice. I think my code is much easier to read now than it was a couple of years ago.Yes, I agree that good formatting is useful, even important, but few people start out formatting their code really well. It should be taught and learned.Mon, 21 Jun 2010 13:27:33 GMTDaniel Bowlinhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxAny thoughts about how to comment a block of T-SQL ?I do this often, but over time I havn't been consistent with it. [code="sql"]/* begin: What I'm doing here is ... */insert ...update ...select .../* end */[/code] [code="sql"]--<What I'm doing here is ... >insert ...update ...select ...--</>[/code] [code="sql"]/* 42: What I'm doing here is ... */insert ...update ...select .../* 42 */[/code]Mon, 21 Jun 2010 11:20:34 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote]What I *really* hate is the clown who decided to name the columns with reserved words...[/quote]Oh sure, we have that; though I can't take credit for it :-P.Select [DateTime] from sometable --It's a case sensitive DB to so it must be "DateTime".Keywords (or any construct) in all caps makes code look very busy to me; like there's more you have to dig thru :unsure:Mon, 21 Jun 2010 10:48:17 GMTken.trockhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxAn interesting point in a style of coding that I’ve come across concerns input parameters in a Stored Procedure. “_in” was put on the end of every input parameter. So if you’re sending the Account number to the procedure, it would be [code="sql"](@Account_in int)[/code]I thought that was a pretty neat indicator to put into the stored procedure to easily find where your input parameters are being used. And then, for anything that is actually output, to put “_out” on the end.Just makes the code a bit tidier in my opinion.Formatted code is a definite plus. Makes debugging the code a lot easier. Whatever style one uses, it should be consistent. The database engine doesn’t worry about the code looking pretty, the guy reading the code afterwards and figuring out what’s now going wrong or how to modify it does.Comments are a luxury the fellow after you wishes you had indulged in. Give that guy a break, comment code. It might be you swearing at the writer trying to figure out what he trying to do. In my job duties, I tend to write ad-hoc queries only, so I’m not commenting much stuff. But the ones that stick around for a while, I comment so I know what they do when I have to pull them out later and the guy who’s coming behind me can more easily figure out what I was doing. Mon, 21 Jun 2010 10:09:22 GMTKit Ghttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxTotally Agree..I too had some hard time understanding the code.. in the mean while cursing the person who developed it so ....... ha ha Mon, 21 Jun 2010 02:41:58 GMTprads.cshttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxWhat I *really* hate is the clown who decided to name the columns with reserved words...[code]SELECT id , database , clientno FROM dbo.AccountsWHERE etc etc[/code]has to become[code]SELECT [id] , [database] , clientnoFROM dbo.Accounts[/code]Why couldn't they have named the columns a little more logically:[code]SELECT accountID , client_group , clientnoFROM dbo.Accounts[/code]EDIT: This was lined up nicely in the preview window :angry:Mon, 21 Jun 2010 00:17:27 GMTniall.bairdhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxSimple thing to do, makes a lot of sense and saves a lot of time down the road.Sat, 19 Jun 2010 16:35:08 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxre: leading commas. It makes them much more visible than when they're off the right side of the screen. Also, it makes it easier to comment a single field from a select clause without having to visit the previous line-end (and uncomment moments later)re: single field or multiple fields per line. Why does it matter how many there are? I don't like to make that decision for how many are too many for a single line - each gets its own line. If you don't have a mouse with a scroll wheel, get one. :)re: fieldalias = expression vs expression as fieldalias. I know it's less portable to go off the standard, but for the same reason as leading commas I like the fieldalias to line up visually. I usually also put tabs before the equal sign so they line up too. Unlike web code (HTML/javascript/css), the cost of whitespace in source is negligible compared to the value of increased readability.re: indentation. following on the value of whitespace, indentation of each component of a clause (Select/fields, From/tables, Where/conditions, etc) makes it easy to see where is occurs because the clause is effectively outdented from the rest. I also indent the ON clause so I can visually separate the table list from their relationship. I think it's also a good idea that the left side of the ON clause should be to the table just mentioned and the right side of the expression should be to the table mentioned previously. That convention is consistent, which also helps reduce confusion.re: delimiters. I know it might seem tedious to square-bracket fields unconditionally but it improves readability especially to indicate the difference between primary keys [tableid] and table names (table). Make wrong code _look_ wrong [1] and you'll be able to spot errors very quickly.[code="sql"]select [fieldA] = coalesce( t1.[fieldA], '') ,[fieldC] = convert( varchar(50), t2.[fieldC]) ,t2.[fieldD]from table1 t1 join table2 t2 on t2.[table1Id] = t1.[table1Id]where t1.[fieldB] = @LookupValue[/code][1] [url=http://www.joelonsoftware.com/articles/Wrong.html]http://www.joelonsoftware.com/articles/Wrong.html[/url] <-- h/t to this author, excellent read.Fri, 18 Jun 2010 22:07:52 GMTMike Dougherty-384281http://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]Nadrek (6/18/2010)[/b][hr]Different styles are different styles, neither good nor bad:SELECT a.c1,a.c2,b.c1FROM db.schema.tbla aINNER JOIN db.schema.tbla bON b.col1 = a.col1 AND a.col2 = b.col2[/quote]Heh... well, except for maybe that leading comma thing that some folks like to use. :-DFri, 18 Jun 2010 21:03:21 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxI appreciate all your comments. I learned a few things as well.I agree that I like to keep my columns on one line unless it spans many lines inwhich I will indent the following lines. I also only add less than 10 columns per row to make sure it doesn't get too long. I also like to indent my joins. I keep all key words capitalized. Like my select statements I like to keep my where clauses the same.Regarding commenting of code: I thought about adding it into this editorial but felt that it only relates to this editorial partially and really is a subject all on its own. Having good commentation does make your code readable but in a different way that what I intended. Commenting your code makes the business logic of the code readable.Fri, 18 Jun 2010 16:07:16 GMTUncleOlliehttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxDifferent styles are different styles, neither good nor bad:SELECT a.c1,a.c2,b.c1FROM db.schema.tbla aINNER JOIN db.schema.tbla bON b.col1 = a.col1 AND a.col2 = b.col2Fri, 18 Jun 2010 15:20:51 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxHere is how I would format the same SQL. I like all lowercase and indent my joins, which makes it easier to read when there are four or more joins.[code="sql"]select a.column_name_1, b.column_name_2from table_1 a join table_2 b on a.table_1_id = b.table_1_idorder by a.column_name_1, b.column_name_2;[/code]If there are only a few columns, then sometimes a string them all on one line like this:[code="sql"]select a.column_name_1, b.column_name_2from table_1 a join table_2 b on a.table_1_id = b.table_1_idorder by a.column_name_1, b.column_name_2;[/code]Fri, 18 Jun 2010 15:15:54 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[code="sql"]select a.COLUMN_NAME_1, b.COLUMN_NAME_2from TABLE_1 a join TABLE_2 b on a.TABLE_1_ID = b.TABLE_1_IDorder by a.COLUMN_NAME_1, b.COLUMN_NAME_2[/code]There, was that so hard?Good developers produce easy to read, easy to follow code. Bad developers produce unreadable, hard to follow code. It's just as simple as that.The only exception to that rule that I have ever seen was a blind developer, but even he at least followed a consistent style that was not that hard to follow.You can argue all you want about a particular style, but having a rule that is actually followed is the most important thing.Fri, 18 Jun 2010 13:49:46 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote]I use SQL indentation, comments, and hungarian notation with underscore for variables that arn't affiliated with a specific column name (ex: @enrollment_date for enrollment_date column and @int_loop for a looping block). Practicaly all of my variable and column names have at least one underscore, because I code all in lowercase. I like coding all in lowercase, because UPPERCASE seems 80's retro, and ProperCase is in my opinion anal-retentive. All I want to think about is wether the object and variable names are descriptive, easy on the eyes, and spelled correctly so it compiles.[/quote]So I use a combination of Hungarian and PascalCasing. Maybe a bit anal-retentive but still better than no system at all. CERTAINLY IT WOULD SEEM THAT ALL UPPERCASE IS NOT EASY ON THE EYES.Fri, 18 Jun 2010 12:45:37 GMTken.trockhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]ken.trock (6/18/2010)[/b][hr][quote]Also, I think it's important to capitalize keywords too. Something handy for that is using highlight the keyword you want to upper case and use Ctrl+Shift+u. Back to one of the the reasons I tab out my data types in my declare if I'm going back through my SQL and I'm cleaning it up I can use a Alt+'mouse select' and Ctrl+Shift+u and it'll upper case the highlight block easily. [/quote]I prefer Hungarian notation with only the 1st letter capitalized but I see that SSMS intellisense is promoting all caps for keywords. Didn't know about Ctrl+Shift+u, nice little trick.I just love it when I have to look into others code and lines are 200 character long; unformatted. There are little if any comments. And everything is lower cased. It looks like the code was written in the last 20 minutes of the project:-D[/quote]I use SQL indentation, comments, and hungarian notation with underscore for variables that arn't affiliated with a specific column name (ex: @enrollment_date for enrollment_date column and @int_loop for a looping block). Practicaly all of my variable and column names have at least one underscore, because I code all in lowercase. I like coding all in lowercase, because UPPERCASE seems 80's retro, and ProperCase is in my opinion anal-retentive. All I want to think about is wether the object and variable names are descriptive, easy on the eyes, and spelled correctly so it compiles.Fri, 18 Jun 2010 12:14:24 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]ken.trock (6/18/2010)[/b][hr]I prefer Hungarian notation with only the 1st letter capitalized but I see that SSMS intellisense is promoting all caps for keywords. Didn't know about Ctrl+Shift+u, nice little trick.[/quote]Formatting and commenting is a must! Set/make/pick some rules and be consistent. Hungarian notation on the other hand not so much. It has lost favor in many places and should also be discouraged in T-SQL as well.MS advises against it (not that they are the definitive ones to follow but...)[url]http://msdn.microsoft.com/en-us/ms229045.aspx[/url]some interesting info on it:[url]http://en.wikipedia.org/wiki/Hungarian_notation[/url]Edit:Unless you are actually talking about Camel Casing? That, as well as Pascal Casing I am for.Fri, 18 Jun 2010 12:14:02 GMTAdam Gojdashttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote]Also, I think it's important to capitalize keywords too. Something handy for that is using highlight the keyword you want to upper case and use Ctrl+Shift+u. Back to one of the the reasons I tab out my data types in my declare if I'm going back through my SQL and I'm cleaning it up I can use a Alt+'mouse select' and Ctrl+Shift+u and it'll upper case the highlight block easily. [/quote]I prefer Hungarian notation with only the 1st letter capitalized but I see that SSMS intellisense is promoting all caps for keywords. Didn't know about Ctrl+Shift+u, nice little trick.I just love it when I have to look into others code and lines are 200 character long; unformatted. There are little if any comments. And everything is lower cased. It looks like the code was written in the last 20 minutes of the project:-DFri, 18 Jun 2010 11:38:00 GMTken.trockhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]Mike B-269836 (6/18/2010)[/b][hr]I am all in favor of appropriate indentation and comments, as well as code reviews. One of the other things that drives me nuts is cryptic naming of columns and variables that make no sense whatsoever. Even with comments and indentation, trying to divine the meaning of cryptic names (particularly in large scripts/stored procedures/objects/etc...) has given me many headaches over my 30ish years in the industry. My rule is to write the comments and the code for the next person. The same for documentation.[/quote]Whenever I write comments for a block of T-SQL code, I imagine that one of the other database developers or managers, who is unfamiliar with the application or project, is standing behind me and asking me the purpose of that code block. After a year or two, if I return to a project that I developed on myself, the comments are useful even for my own understanding.Fri, 18 Jun 2010 10:57:03 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxI am all in favor of appropriate indentation and comments, as well as code reviews. One of the other things that drives me nuts is cryptic naming of columns and variables that make no sense whatsoever. Even with comments and indentation, trying to divine the meaning of cryptic names (particularly in large scripts/stored procedures/objects/etc...) has given me many headaches over my 30ish years in the industry. My rule is to write the comments and the code for the next person. The same for documentation.Fri, 18 Jun 2010 10:12:45 GMTMike B in AKhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxVisual Studio formats code automagically. Our TSQL editors should too, that way we know what we [i]really [/i]wrote. Of course I will admit to wondering what will fall out as I format TSQL written by others. Bill JFri, 18 Jun 2010 09:28:34 GMTbill.joneshttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxFormatting and indenting is fundamental. Using a formatting tool can help a whole team sharing the same formatting standards, which is something that makes the effort even more meaningful and rewarding.As far as becoming replaceable, this should be seen as positive: if you're not replaceable you will keep on doing the same things over and over and never improve your career.Fri, 18 Jun 2010 09:00:09 GMTspaghettidbahttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxI agree in part, and disagree in part.I agree that readable code, with tags on End If and other blocks so current or future nesting is readable, is important.I disagree that it's critical for formatting to be done by the initial developer; so much of that is a matter of style it's not even funny. Rather, I suggest that every developer have their preferred settings in a SQL Beautifier (like the C beautifiers of old), so when they really object to the formatting of some code, push a few buttons or copy/paste, and it's in that developer's own preferred format. Next developer, same thing.Doing 100% consistent, very tedious things is exactly what software excels at; let software make code 100% consistently formatted according to a set of rules.So, I would ask: what are the good SQL beautifiers available today that can save a set of detailed rules? ON clause on a new line or not, indented or not, indenting AND's or not, AND/OR at the beginning or the end, and so on and so forth.Fri, 18 Jun 2010 08:55:12 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxWe use SQL Assistant [url]http://www.softtreetech.com[/url] for multiple functions among them code formatting. SQL Assistant uses formatting templates that can be tailored for each user. This allows us to have our individual styles giving us the ability to format a colleage's code with just two key strokes (by default) ctrl + F11 to our liking.The only problem with inconsistent formatting styles comes from code diffs during version control, but for the most part it's not an issue.Fri, 18 Jun 2010 08:53:21 GMTBradley Deemhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxI think this is one place where the lack of code reviews happening is hurting code. When multiple people have to work with code, standards and comments get enforced fairly quickly to ensure readability.Reviewing code people submit here in articles, I've seen some truly horrendous formats submitted that make it hard to follow the code.Fri, 18 Jun 2010 08:33:59 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspx[quote][b]gabriel.raymer (6/18/2010)[/b][hr]READABILITY is a must. ... I can use a Alt+'mouse select' ...[/quote]I do everything you said gabriel, plus reducing my tabs to 3 spaces so I can use indentation without eating up the whole page (good to have a team standard on that as well), but OMG I did not know this!!! Thank You!!Fri, 18 Jun 2010 08:06:18 GMTkatedgrthttp://www.sqlservercentral.com/Forums/Topic939334-263-1.aspxI strongly agree with the benefits of formatting as described in the editorial, but why leave this at an individual level?Formatting and commenting standards should be set at a company level because consistancy is a very important part of this equation. Ideally, any developer can read any other developer's code and not be able to distinguish who wrote what based on formatting. I have been a developer since 1981 and have found that this principle will never fail your company. Also fire the SOB who writes sloppy code intentionally for job security. True job security (if there can be such a thing in this age) is found by being among the best at what we do: writing fast, efficient, defect free, and maintainable code at a rapid pace.Sam FrabottaFri, 18 Jun 2010 07:53:18 GMTSamJazz