December 19, 2015 at 1:24 pm
Comments posted to this topic are about the item Decorations
December 21, 2015 at 1:49 am
One statement I read is how I code:
"Code is for humans, not machines."
So how someone codes tells a lot how they see interaction with other humans.
Code is documentation that I leave for others to understand what I thought. As one of my mentors said:
"Documentation is half the job. Are you doing a full job?"
December 21, 2015 at 6:24 am
A side-effect of comments is that it should make the purpose of the code obvious. It helps locate bugs when the intent doesn't match the implementation. Such as your example:
--Find the largest ornament on the tree
SELECT TOP 1 @ornamentId=OrnamentId, @treeOrnamentId = TreeOrnamentId
FROM Tree
JOIN TreeOrnament
ON Tree.TreeId = TreeOrnament.TreeId
JOIN Ornament
ON TreeOrnament.OrnamentId = Ornament.OrnamentId
WHERE TreeYear = '2015' --Pick the tree for the current year
ORDER BY Ornament.Size
Clearly now, the intent was to find the _largest_ ornament. What the example shows, by using the default ascending order of Size instead of specifying descending order, is picking the _smallest_. Simple to find when you have the additional information provided by the comments and you're looking objectively.
Whether your mistake was intentional or unintentional, it makes a good case that comments help with programming.
December 21, 2015 at 6:33 am
"SQL code is amongst the worst code to parse without proper formatting."
Incorrect. SQL code will parse just fine without proper formatting.
December 21, 2015 at 8:42 am
eeaglehouse (12/21/2015)
A side-effect of comments is that it should make the purpose of the code obvious. It helps locate bugs when the intent doesn't match the implementation. Such as your example:
--Find the largest ornament on the tree
SELECT TOP 1 @ornamentId=OrnamentId, @treeOrnamentId = TreeOrnamentId
FROM Tree
JOIN TreeOrnament
ON Tree.TreeId = TreeOrnament.TreeId
JOIN Ornament
ON TreeOrnament.OrnamentId = Ornament.OrnamentId
WHERE TreeYear = '2015' --Pick the tree for the current year
ORDER BY Ornament.Size
Clearly now, the intent was to find the _largest_ ornament. What the example shows, by using the default ascending order of Size instead of specifying descending order, is picking the _smallest_. Simple to find when you have the additional information provided by the comments and you're looking objectively.
Whether your mistake was intentional or unintentional, it makes a good case that comments help with programming.
Two things:
1. It did make that unintentional point, didn't it 🙂
2. It also says that it was posted before I made my last edit :). The version I have that I am finalizing for Simple-Talk has this as DESC :).
3. (Bonus) It proves that someone actually reads these things in detail 🙂
Thanks! And Happy Christmas and Merry Holidays
December 21, 2015 at 8:47 am
patrickmcginnis59 10839 (12/21/2015)
"SQL code is amongst the worst code to parse without proper formatting."Incorrect. SQL code will parse just fine without proper formatting.
In this case, the word parse was more meant as for humans. Since you don't have any required punctuation,
DECLARE @o int, @t_o int SELECT TOP 1 @o=O, @t_o=T_O FROM T JOIN T_O ON T.T = T_O.T JOIN O ON T_O.O = O.O WHERE Y = '2015' ORDER BY O.S DESC SELECT O,B,D FROM O WHERE O= @o DELETE T_O WHERE T_O = @T_O
Works fine. And take a select statement:
SELECT TOP 1 @o=O, @t_o=T_O
FROM T
JOIN T_O
ON T.T = T_O.T
JOIN O
ON T_O.O = O.O
WHERE Y = '2015'
ORDER BY O.S DESC
Formatting like this is common, as people treat JOIN and ON as clauses, so this statement isn't as clear as:
SELECT TOP 1 @o=O, @t_o=T_O
FROM T
JOIN T_O
ON T.T = T_O.T
JOIN O
ON T_O.O = O.O
WHERE Y = '2015'
ORDER BY O.S DESC
With the major clauses (no holiday pun intended) If I can change this, I will make that more clear in the post here, but certainly on Simple-Talk, I will.
Thanks for the reply, and Happy Holidays, Merry Christmas, and a New Year filled with more interesting posts by lots of people to read and pick apart (I love being picked apart in a nice way. I like to learn stuff)
December 21, 2015 at 8:55 am
Knut Boehnert (12/21/2015)
One statement I read is how I code:"Code is for humans, not machines."
So how someone codes tells a lot how they see interaction with other humans.
Code is documentation that I leave for others to understand what I thought. As one of my mentors said:
"Documentation is half the job. Are you doing a full job?"
Agree wholeheartedly. The hardest part is determining how much is too much. For example:
--show the details of the ornament chosen
SELECT OrnamentId, Branch, Description
FROM Ornament
WHERE OrnamentId = @OrnamentId;
I prefer that people just note what the statement is doing unless there is something interesting going on ( like an = ANY() operator!), but sometimes you get someone who does:
--show the details of the ornament chosen
SELECT OrnamentId, Branch, Description --there are other columns, but these are the ones we need because it is all that
FROM Ornament --from the Ornament table that has details about the Ornaments in the collection
WHERE OrnamentId = @OrnamentId; --find a certain ornament with the key equal to the variable
--once the client fetches the rows, the following statements will execute:
And eventually (after a bit of thankfulness that comments are color coded in SSMS), you want to pull your hair out looking for the comments that tell you what the purpose of the statement is, and not metadata that you could easily look up, or obvious things like what an = operator does.
So the question becomes, do you see your fellow people as idiots who can't figure out SQL, or as people you don't care about because you are going to leave someday (and you can figure out what you did), or as peers on a high enough level to not be confused by an = expression.
Merry Christmas. Thanks for reading the post (and don't take it as a slight that I didn't say more about New Years. I just couldn't think of more to say and this explanation is longer than it would have been to say Happy New Year!)
December 21, 2015 at 9:13 am
Thanks for the article. One of the worst pieces of advice I heard early in my career was: "Code is its own documentation." Fortunately, I never agreed with that.
Hakim Ali
www.sqlzen.com
December 31, 2015 at 7:49 pm
What am awful article. The idea or putting code into some ghastly image format so that no-one can copy i and run it through whatever analysis tools they want to use is just plain loony. It certainly ensures that no-one who doesn't have other things to do will look at it, which probably means it won't get many nasty comments, but it also ensures that it will be useless for most readers.
What other aim could this silliness imaginably have than to prevent people from criticising the article?
Tom
January 1, 2016 at 7:35 am
Louis Davidson (@drsql) (12/21/2015)
patrickmcginnis59 10839 (12/21/2015)
"SQL code is amongst the worst code to parse without proper formatting."Incorrect. SQL code will parse just fine without proper formatting.
In this case, the word parse was more meant as for humans.
I would use "hand parse" if you're specifically talking about a human parsing, this is a computer forum and I think its a better match.
And if you hadn't used pictures for code, like Tom said, we could have even slapped your examples into a pretty printer and ventured into a discussion about why we even need to hand parse SQL nowadays.
Additionally, you just threw out there that "SQL code is amongst the worst code to parse without proper formatting," like it wasn't even refutable. What about perl? c? ever read the "esoteric programming languages" topic on Wikipedia?
https://en.wikipedia.org/wiki/Esoteric_programming_language
Go hand parse some of that mess and you'll know real pain.
I don't think in reply to my post you needed to reiterate your entire article, but that could just be your style I guess.
I also think that your article really didn't dig into the subject to my satisfaction. Maybe I am just picky, but understanding code and systems is one of my favorite topics.
January 1, 2016 at 2:56 pm
TomThomson (12/31/2015)
What am awful article. The idea or putting code into some ghastly image format so that no-one can copy i and run it through whatever analysis tools they want to use is just plain loony. It certainly ensures that no-one who doesn't have other things to do will look at it, which probably means it won't get many nasty comments, but it also ensures that it will be useless for most readers.What other aim could this silliness imaginably have than to prevent people from criticising the article?
You got me. That is why I put it into a picture and not to ensure poor formatting. And the code itself isn't really the point, and neither was the design. I started with a single table And ended with three to get closer to a right design, but the point was that poorly formatted code sucks to read, and that it is easier to follow if you format.
Criticize all you want, my skin is thick enough to handle it. It was just a simple blog about how each iteration was better than the next, not that it was perfect :). Happy New Year!
January 1, 2016 at 3:09 pm
patrickmcginnis59 10839 (1/1/2016)
Louis Davidson (@drsql) (12/21/2015)
patrickmcginnis59 10839 (12/21/2015)
"SQL code is amongst the worst code to parse without proper formatting."Incorrect. SQL code will parse just fine without proper formatting.
In this case, the word parse was more meant as for humans.
I would use "hand parse" if you're specifically talking about a human parsing, this is a computer forum and I think its a better match.
And if you hadn't used pictures for code, like Tom said, we could have even slapped your examples into a pretty printer and ventured into a discussion about why we even need to hand parse SQL nowadays.
Additionally, you just threw out there that "SQL code is amongst the worst code to parse without proper formatting," like it wasn't even refutable. What about perl? c? ever read the "esoteric programming languages" topic on Wikipedia?
https://en.wikipedia.org/wiki/Esoteric_programming_language
Go hand parse some of that mess and you'll know real pain.
I don't think in reply to my post you needed to reiterate your entire article, but that could just be your style I guess.
I also think that your article really didn't dig into the subject to my satisfaction. Maybe I am just picky, but understanding code and systems is one of my favorite topics.
Good points. Yes, there are code for matters that would get from the poorly formatted code, and I use them regularly due to funky code.
And I will agree that other code types are terrible too, hence I said "amongst" the most difficult. Since you don't seem a statement terminator, weird formatting errors happen all of the time. I found some code the other day in an SSIS package that said:
Select <columns>
From. TableName
GO
That worked great. Only GO doesn't work in a SQL operator in SSIS. GO was used as an alias instead of a batch separator.
In terms of how deep I go in these blogs, it is what they want. Short topics. My reply is more my style, writing deeply and covering every angle and doing research for all of the cases. But these are simple opinion blogs, just noting one factor that makes for good database pros, and the code was just a simple holiday oriented example of how the same code was unreadable to start with, then applying some formatting and naming... And there I go again restating it again 🙂
Appreciate the reply, have a super holiday season (at this point, the next 366 days!)
January 1, 2016 at 6:29 pm
TomThomson (12/31/2015)
What am awful article. The idea or putting code into some ghastly image format so that no-one can copy i and run it through whatever analysis tools they want to use is just plain loony. It certainly ensures that no-one who doesn't have other things to do will look at it, which probably means it won't get many nasty comments, but it also ensures that it will be useless for most readers.What other aim could this silliness imaginably have than to prevent people from criticising the article?
Heh... perhaps it's to prevent people from fixing the right margin hyphenated words in the code that won't make it past the parser? 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2016 at 11:22 am
I'm pretty particular on the formatting of my code, for the very reasons of readability and maintainability. I can write format that'll confuse anyone, including myself, but why on earth would I let haphazardly-formatted code into production. It inhibits progress during development and later modifications, so it's a serious disservice to myself and others.
On a related note, I also take the radical step of including comments. If nothing else, it'll tell me what I was thinking when I originally wrote it. If it's been two years since I touched it, I really benefit from seeing the overall approach and comments I left myself. I also really appreciate it when others do the same. An important point is to update the comments so they match the code.
None of this is really controversial and shouldn't take anyone off-guard. However, it's still something many people don't do.
January 2, 2016 at 11:38 am
Ed Wagner (1/2/2016)
I'm pretty particular on the formatting of my code, for the very reasons of readability and maintainability. I can write format that'll confuse anyone, including myself, but why on earth would I let haphazardly-formatted code into production. It inhibits progress during development and later modifications, so it's a serious disservice to myself and others.On a related note, I also take the radical step of including comments. If nothing else, it'll tell me what I was thinking when I originally wrote it. If it's been two years since I touched it, I really benefit from seeing the overall approach and comments I left myself. I also really appreciate it when others do the same. An important point is to update the comments so they match the code.
None of this is really controversial and shouldn't take anyone off-guard. However, it's still something many people don't do.
Heh... I don't write comments for other people. I write them for ME because I have a major CRS problem. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply