Just how hard is it...
-
to format SQL??? Really, does a large stored procedure have to be on as few lines as possible? I can't believe the author didn't just make it a single line and be done with. Oh, and as few spaces as possible. Now I have to format it just so I can begin to get a to grips with why it isn't doing what it is supposed to be doing. :mad::mad::mad:
Youare
right I
alw ays f
orm a
t my
codewithsp a
c
e
s an d
n ewli
nes wh er
appropriat e:
)Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Youare
right I
alw ays f
orm a
t my
codewithsp a
c
e
s an d
n ewli
nes wh er
appropriat e:
)Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Very good. :laugh:
-
to format SQL??? Really, does a large stored procedure have to be on as few lines as possible? I can't believe the author didn't just make it a single line and be done with. Oh, and as few spaces as possible. Now I have to format it just so I can begin to get a to grips with why it isn't doing what it is supposed to be doing. :mad::mad::mad:
-
Rubbish. Doesn't format it my way.
-
to format SQL??? Really, does a large stored procedure have to be on as few lines as possible? I can't believe the author didn't just make it a single line and be done with. Oh, and as few spaces as possible. Now I have to format it just so I can begin to get a to grips with why it isn't doing what it is supposed to be doing. :mad::mad::mad:
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
-
to format SQL??? Really, does a large stored procedure have to be on as few lines as possible? I can't believe the author didn't just make it a single line and be done with. Oh, and as few spaces as possible. Now I have to format it just so I can begin to get a to grips with why it isn't doing what it is supposed to be doing. :mad::mad::mad:
-
When I was learning to program (a long, long time ago), I was told that untidy code always contained more errors that tidy, well laid out code. If the programmer was too lazy to lay the code out neatly, what else was he too lazy to do.
My experience shows that to be a universal truth. Every programmer I've ever met who wrote sloppily formatted code had sloppy logic as well. Unfortunately, the reverse is not true. Tidy code does not guarantee tidy logic. In the terms our logician friends would use, tidy source code is a necessary but not sufficient condition to have tidy logic.
Software Zen:
delete this; -
Thanks: have used that before and there are a couple of others. However, not the point. I shouldn't have to do that to existing code. Messy, inconsiderate, lazy buggers. :)
R. Giskard Reventlov wrote:
Messy, inconsiderate, lazy buggers.
Are you sure you're in the right line of work? Then again, you'll encounter that in any profession. :) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
When I was learning to program (a long, long time ago), I was told that untidy code always contained more errors that tidy, well laid out code. If the programmer was too lazy to lay the code out neatly, what else was he too lazy to do.
My experience has been that people who write messy code, don't really understand it --- they mostly just copy'n'pasted it from somewhere, and then hacked at it until it (sorta) worked. It looks like a black box, because they view it as a black box: data goes in, magic happens, data comes out and no one knows why. Recently, I attended a lecture on functional programming in C#. Most of the audience was rather quiet and I was the only one asking questions. One line of code was like this:
return b => a => a + b;
After a bit of prodding, I got him to rewrite it as:
return (b)=>
{
return (a) => { return a + b; }
}And suddenly, the room came alive where finally everyone realized what the line was doing.
Truth, James
-
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
This is what I use: keyboard duh[^]
onwards and upwards...
-
to format SQL??? Really, does a large stored procedure have to be on as few lines as possible? I can't believe the author didn't just make it a single line and be done with. Oh, and as few spaces as possible. Now I have to format it just so I can begin to get a to grips with why it isn't doing what it is supposed to be doing. :mad::mad::mad:
When I allowed Microsoft's SQL tools to re-interpret my code, they not only shoved it into as few lines as possible, but actually pulled apart the Boolean logic in moderately complex WHERE clauses and rewrote them with unnecessary repetitions of elements interspersed with extra AND's and/or OR's so that I couldn't even understand my own logic. Lots of guys like to use Microsoft's code generation tools, resulting in code like that, but they don't even try to look at the code, they just work from the code generation tool. So, maybe what you're seeing isn't even coded directly by a human. What I did is to take over the code, always formatted and saved it in a way that bypassed the code generation crap, and explained to the other developers how my code worked and why it was best to keep it formatted like I did, or they would never be able to understand and modify it.
-
My experience has been that people who write messy code, don't really understand it --- they mostly just copy'n'pasted it from somewhere, and then hacked at it until it (sorta) worked. It looks like a black box, because they view it as a black box: data goes in, magic happens, data comes out and no one knows why. Recently, I attended a lecture on functional programming in C#. Most of the audience was rather quiet and I was the only one asking questions. One line of code was like this:
return b => a => a + b;
After a bit of prodding, I got him to rewrite it as:
return (b)=>
{
return (a) => { return a + b; }
}And suddenly, the room came alive where finally everyone realized what the line was doing.
Truth, James
And then he realized that you write code for people, not compilers. compilers don't care (in most cases) about format, but good format aid in the understanding of the code by others, and yourself when you have to debug or maintain it.
-
Rubbish. Doesn't format it my way.
It really is quite a good, flexible tool, with many options. If the online options aren't good enough for you, fork over a few $$ and buy the full version, which has even *more* options.
-
to format SQL??? Really, does a large stored procedure have to be on as few lines as possible? I can't believe the author didn't just make it a single line and be done with. Oh, and as few spaces as possible. Now I have to format it just so I can begin to get a to grips with why it isn't doing what it is supposed to be doing. :mad::mad::mad:
I always format my SQL, because I maintain the master in .txt or .sql files. Unfortunately, many systems reformat it for you - SQL Server among them. Which is otherwise far better than Oracle or DB/2. That is one of the things I detest about most IDEs (especially Visual Studio). They reformat my carefully formatted code.
-
I always format my SQL, because I maintain the master in .txt or .sql files. Unfortunately, many systems reformat it for you - SQL Server among them. Which is otherwise far better than Oracle or DB/2. That is one of the things I detest about most IDEs (especially Visual Studio). They reformat my carefully formatted code.
