March 27, 2016 at 12:03 pm
diamondgm (3/26/2016)
diamondgm (3/26/2016)
The results should be visible hereIf the BI gods do their thing, the report should update hourly
You should also be able to download the data by clicking on the ellipsis of any of the cards and electing to export data.
The downloaded format will be csv
Click on "here" - it will take you to a Power BI dashboard.
You can also download the data by click on an items ellipsis.
That worked fine on the day you originally posted the link. Now it's asking for a login for the Power BI site.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2016 at 12:11 pm
Sorry about that guys - I've not shared items outside our organisation and was not sure how Power BI would behave; it is a new feature.
You should be able to get the results here; the sheet is live (it is populated directly by the survey form)
Please let me know of any other issue I might be able to help with
March 27, 2016 at 1:03 pm
The survey results so far look pretty much in favour of having some sort of formatting standard, but the number responding is very small which maybe indicates that a lot of people don't care enough about formatting (whether in favour of having a standard or against) to be bothered with the survey.
Me, I'm in favour of well formatted code, whatever kind of language it's in. I don't insist that everyone conforms exactlt to some rigidly fixed layout rules, but i dod insist tht the code be laid out in such a way as to make its structure obvious and facilitate understanding and code that is hard to read because of poor layout is totally unacceptable - so I'm a 4 on that survey, not a 5, perhaps because I used to get really pissed off when power-mad lunatics insisted that all indents should have 6 em width (or started a feud over whether it should be 5 em or 5) and picking option 5 looks like advocating that sort of bone-headed stupidity.
The editorial contains the nonsense claim that we don't bother with formatting text, but of course we do - and we do it differently in different languages. In some languages some punctuation marks have to be preceded by a space, for example; there's often some way of indicating quoted speech with something more than English's simple quotation marks; most editorial style standards for English require a double space after a full stop, so that sentence boundaries are more obvious than with a single space; and paragraph boundaries are very clear in the normal layouts of every language I know. And it ties the idea of using indentation to make structure clear to procedural languages, as if these were the only (computer) languages which have any structure - I can confirm that indentation has been widely used to make structure more obvious by people wrting in declarative languages, including functional language and logic-languages, and that it wasn't much used in early procedural languages (there was not much room for clever layout on a punched card).
But Phil is right when he sys that taken too far formatting stndrds (for any language) can have a negative effect on productivity and code quality. Enforcing a standard that the writers are not comfortable with is usually a bad idea, and sometimes a poisonously terrible one. And any standard that causes good people to look for jobs elewhere is worse than useless.
Tom
March 28, 2016 at 6:55 am
It is good form to make the results visible without a login, thank you for posting that external link
412-977-3526 call/text
March 28, 2016 at 7:45 am
Readability matters nearly as much as accuracy and performance.
Agree with the comments and the others along this line. Phil's comments that it may look silly with a simple statement or it can get complicated with uncommon sections (as I understand it) shouldn't detract that there should be a standard that all understand and abide by.
I've even seen inconsistency by the same writer in the same stored procedure. For some things, such as capitalization of key words, I simply expect consistency by the same writer. Not that I don't have an opinion on the issue (UPPERCASE), but among younger programmers who have never worked with a non-color coding interface, it doesn't seem to be so important. It's a tough line to draw, and I can understand those who might be stricter than I.
March 28, 2016 at 7:53 am
I'm sure Mr Factor had an evil smirk on his face when he wrote this. The survey results lend weight to my supposition 😉
Having worked in a variety of different organisations on literally dozens of different databases all with their own style, I don't hold grudges against people who have developed their own particular formatting preferences. Having said that...
Personally I really do find it easier to spot bugs if I can take advantage of the columnar nature of a repetitious white-space agnostic language like TSQL. So if it is possible to line certain things up vertically it's much easier to spot certain problems. The missing leading comma is much easier to spot than the missing trailing one (to me). The "accidental aliases" are another good example where a neat quasi-columnar layout can save me time in the long run.
Tools like Mladen Pradjic's SQL Snippets (in the SSMS Tools Pack) are so easy to use that they make a mockery out of the argument that it takes too long to format neatly.
My real pet hate is saving tabs as tabs instead of spaces. For the sake of a handful of bytes in file size, saving as tabs means that everyone who opens the code with a different tab setting to the original author is met with an unholy mess. To say "oh everyone should just follow the organisation's policy of tabs being X characters in width", doesn't seem to work in my experience. If you configure SSMS to write out your tabs to spaces it will ALWAYS display exactly the way you wrote it regardless of the TAB settings on the machine in question.
Incidentally has anyone worked out a regex find and replace (or similar way) to get rid of tabs BUT replace them with exactly the desired number of characters? In other words, your TAB setting might be notionally 4 chars, but depending on what they line up with, they can also be 3, 2, or 1, so replacing each TAB with 4 chars (in this case) can cause a mess. I've got it down to a minimal number of keystrokes, but it's still tedious. SSMS's built-in Untabify, only untabifies the leading tabs on a line; the ones that appear after other characters remain.
...One of the symptoms of an approaching nervous breakdown is the belief that ones work is terribly important.... Bertrand Russell
March 28, 2016 at 9:01 am
I do care about formatting. I find it much easier to read code that's formatted in a specific way (much easier to understand and much easier to spot mistakes).
That said, I don't like to enforce my standard on others and I wouldn't enjoy having someone else's standard imposed on me. Never mind the lost productivity of reformatting - the lost productivity of getting code rejected for cosmetic reasons, plus the potential endless discussion about whether to change a particular standard would be soul-torturing.
Leonard
Madison, WI
March 28, 2016 at 9:36 am
Clean SQL runs better for the same reason that a clean car runs better. It's simply that those same developers who take time to format their code in a meaningful way tend to also know better how to write and maintain it. When a 1,000 line stored procedure looks like it was quickly cobbled together by pasting blocks of SQL from other procedures or code generators in a haphazzard manner... it probably was.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 28, 2016 at 10:29 am
diamondgm (3/26/2016)
The results should be visible hereIf the BI gods do their thing, the report should update hourly
You should also be able to download the data by clicking on the ellipsis of any of the cards and electing to export data.
The downloaded format will be csv
Says we need an account to log in and see the results, or at least that is what happens when I clink on the link provided.
March 28, 2016 at 10:36 am
I had a coworker at a previous employer where I was actually writing PL/SQL :sick: that had TOAD set up to format the code the way he liked it. I never got around to it but I could have done the same for myself.
His idea was that each developer could format the code the way they preferred and when he would look at it he would format it to his preference. He also suggested checking the code into SVN unformatted. Not sure if I would go that far, but I do agree that code needs to be formatted to be easily read by humans and that a company should have a standard that all developers adhere to when writing code.
March 28, 2016 at 10:49 am
I go for carefully structured code every time. I work in a 1-programmer environment in a small company, but every bit of SQL that I produce, even one-use queries that I key directly into the SQL Server Management Studio and don't save, is carefully structured for readability. I have found that going for speed of input can cause mistakes to go unnoticed. Mistakes that produce invalid SQL are only minor time wasters, but mistakes that produce valid SQL can cause problems that take hours to fix.
Since I am the only programmer where I work, code reviews are not a problem, but long-term readability is - I support many locally-written applications that have a lot of SQL embedded in the source code, and when I need to modify something that I wrote 5 years ago, I need to be able to understand what I wrote, and good structure in that code saves a lot of time.
It would be interesting to see some comparisons of structuring techniques. Perhaps you could post a sample of totally unstructured SQL and challenge your readers to show how they would structure it, with a bit of explanation of the formatting philosophy.
March 28, 2016 at 1:45 pm
Eric M Russell (3/28/2016)
Clean SQL runs better for the same reason that a clean car runs better. It's simply that those same developers who take time to format their code in a meaningful way tend to also know better how to write and maintain it. When a 1,000 line stored procedure looks like it was quickly cobbled together by pasting blocks of SQL from other procedures or code generators in a haphazzard manner... it probably was.
If produces a 100 line stored procedure it seems to me that there are very few possible reasons:-
(a) a formatting standard that permits no more than 4 characters per line
(b) a desire to include a user manual in the comments, plus a description of all the unit tests and their results
(c) an unwillingness to break things down into units that people have a reasonable chance of understanding
(d) total incoapacity to write straightforward code
(e) the author intended to take the piss out of the reviewers
I guess there may be more possible reasons, but I can't imagine ny of them being more accepatble than even the lest acceptable of the above.
Most stored procedures should fit onto a page (A4 or American letter) - say 60 lines of tex using sensible font. A page and a half or two pages might be cceptable in some cases. Anything bigger should be broken dow into chunks small enough to be taken in at one bite, because one outer procedure that uses ten inner procedures, ech of about 100 lines, is a bunch of code that will inevitably be far easier to understand than a single stored procedure of 1000 lines.
edit: so here I'm displaying my willingness to enforce a standard, which i suppose might be called a layout standard: a standard that says "your code must come into reasonbly small units, in a form that allows the units lower in the hierrchy to be tested independently". That's not really a layout standard, though.
Tom
March 28, 2016 at 1:55 pm
TomThomson (3/28/2016)
...Most stored procedures should fit onto a page (A4 or American letter) - say 60 lines of tex using sensible font. A page and a half or two pages might be cceptable in some cases. Anything bigger should be broken dow into chunks small enough to be taken in at one bite, because one outer procedure that uses ten inner procedures, ech of about 100 lines, is a bunch of code that will inevitably be far easier to understand than a single stored procedure of 1000 lines.
...
The stored procedure I'm currently tasked with refactoring reads like a 20 page short story by Clive Barker.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 28, 2016 at 1:55 pm
Lynn Pettis (3/28/2016)
diamondgm (3/26/2016)
The results should be visible hereIf the BI gods do their thing, the report should update hourly
You should also be able to download the data by clicking on the ellipsis of any of the cards and electing to export data.
The downloaded format will be csv
Says we need an account to log in and see the results, or at least that is what happens when I clink on the link provided.
Try https://onedrive.live.com/redir?resid=4D0361FD49E9910!17467&authkey=!ALpeWykjDf2k2zU&ithint=file%2cxlsx, no login needed.
Tom
March 28, 2016 at 1:57 pm
With 61 responses here are some basic stats:
ratingcount
10
21
36
431
523
61
Yearscount
0-56
5-1012
10-1513
15-2015
20+15
61
412-977-3526 call/text
Viewing 15 posts - 16 through 30 (of 56 total)
You must be logged in to reply to this topic. Login to reply