|
|
Posted by Steve on 11/08/07 21:35
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:I8idnbCucsiO867anZ2dnUVZ_ournZ2d@comcast.com...
> Steve wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>> too much space? is there a premium on space in your editor, jerry?
>>>> would you like me to post a query i have for running financial
>>>> statistics here? i would be more than willing to un-format it so just a
>>>> single line in order to save 'virtual' space on the 'virtual' page if
>>>> you'd like. :)
>>>>
>>> Don't be an asshole again, Steve. My editor isn't limited, but my
>>> screen size is, and that wastes a lot of it.
>>
>> again? when was i being an asshole at all, jerry? i was sarcastically
>> making a point. one of which is that your screen realestate is far less
>> expensive than spending the time it takes to debug non-functioning
>> queries...especially when the query is more complex that what it seems
>> you've written in the course of your experience. you'd probably start by
>> *formatting* said query so you could break it down and isolate the
>> problem. after all of that's done, you probably would spend a fraction of
>> time fixing the actual problem. if it is formatted to begin with, you are
>> less likely to introduce problems, more able to expand a query, and very
>> quickly able to fix whatever else may ail it.
>>
>
> First of all, it didn't come through as sarcastic. If that is how it was
> meant, then I apologize.
that's fine.
> But this is simple compared to many of the queries I've written in the
> past. Try recursive queries in DB2 or Oracle, for instance. Some of them
> get very long and very complicated. But I doubt you are even aware of
> what a recursive query is.
here we go again, jerry! can you cut down on the overassumptive insults? i'd
stack my 25 years of programming experience against yours any day of the
week. yes, i know what recursion is an any context - even this one where you
continually fall back into the same pattern of insult after insult. most
recursive functions have a drop-out condition so it's not an endless loop.
what's yours?!
> And I didn't say don't format - you're putting words in my mouth. I said
> your method of formatting is lousy.
well, first you said you didn't care for mine. then you said mine was
stupid. now it's just lousy...all the while missing the point that
FORMATTING is what was being discussed, not MY FORMATTING STYLE. i couldn't
care less about your thoughts on my style...just as you probably mirror in
my reflections on yours, or anyone else's for that matter.
if you stick to the point (formatting) then i'll be far less likely to
assume my 'method' you originally stated disagreement with means 'formatting
in general' instead of 'steve's particular formatting style'. and were that
the case, i'd have said 'i don't care how you feel about it, jerry'. as it
is, you went on a tangent while the rest of us were still talking about
*formatting* - regarless of styles.
>> if it's that big of a deal, buy an editor with code folding.
>>
>> again, am i an asshole simply because i have been calmly disagreeing with
>> you?
>>
>
> It's the way you disagreed.
he, he, he. calmly? come one jerry! you've seen enough of my posts to know
when i'm being an ass or tryin to be one. i think something just went wrong
for you today and your sensitive about something wholly unrelated.
>>>> as far as being 'correct by virtually any programmer i [you]
>>>> know'...that may be as 'virtual' as the space such a query takes up. as
>>>> for what is reported, documented, and written about code formatting -
>>>> inclusive of sql - i think you're outnumbered.
>>>>
>>> Yep, programmers with any sense don't do it that way. The do it similar
>>> to:
>>>
>>> SELECT a,b,c
>>> FROM x
>>> WHERE y='z';
>>>
>>> Or something similar. And in the almost 25 years I've been doing SQL, I
>>> can probably count on two hands the number of experienced programmers
>>> who write SQL as you did. And hundreds who do it the way I learned.
>>
>> you know what? me too. however, those handful are the ones from whom i
>> learned the most. they showed me that consistency, simplicity, and
>> manageability are the keys to not only good code, but a successful
>> career.
>>
>
> Sure. And what do you do when you have a recursive query with 50
> different parameters from 5 joined tables with a half dozen conditions
> (not including the joins)? I've had queries run upwards of 2K characters.
what? jerry, the larger and more complex a query, the MORE you need to
format it - indenting, aligning, etc.. i'm not sure i follow where you're
wanting to take this.
> Let's see you format THOSE queries the way you espouse and get them on in
> a single window in something larger than 1 point font.
you're putting the criteria on it, not me. i couldn't care less if it fit in
a single window or if it required multiple caches to cleanly scroll through
the whole thing.
are you telling me that it is best to leave queries unformatted, especially
the more complex in nature they become? either you're digging your own grave
here, or, you're still stuck on my particular style of code formatting. if
the latter, i could give a flying fuck. if the latter, there's no need to
continue the conversation, mainly because you have yet to address my one and
only point - format your fucking sql statements. and just for you jerry,
since you still can't catch on...i don't care how anyone stylistically
formats their sql in particular. to each their own on that issue. now let's
move on.
>> also, in addition to being an asshole for disagreeing with you, jerry,
>> i'm now a programmer without any sense...and for simply the same reason?!
>> rof.
>>
>> i'm chuckling even more now though. don't you notice a difference between
>> the example you gave:
>>
>> select a, b, c
>> from x
>> where y='z'
>>
>> and the real formatting issue being discussed here...in the genre of:
>>
>> select a, b, c from x where y='z'
>>
>
> No, it's the difference between
>
> select a, b, c
> from x
> where y='z'
>
> and
>
> select
> a,
> b,
> c
> from
> d
> where
> y='z'
>
> Now - which one is more readable?
in my opinion:
SELECT a ,
b ,
c
FROM d
WHERE y = 'z'
is most readable and manageable...esp. when i want to add new fields to the
query. i go to the select, hit enter, drop the new field in. if it's all
listed, i'm just adding to a pool. ever have a problem of selecting the same
field twice in the same query? i never have. i can clearly see what fields
i'm working with. notice that i even align my commas and keep them
measurably out of the way of the field list so as not to disturb my view?
and yes, i even align my equations so i get a list of things and how each
relates to some other thing (i.e. y = 'z', etc.).
again though, this is your tangent...not mine. as far as your stylistic
practices or mine, i don't care. formatting v. not formatting. keep
repeating that to yourself jerry. enough times so that it will eventually
sink in that that was my point. then you'll quit arguing over non-sense.
>> hmmmm...the former being formatted in some way, the latter, not at all.
>> and i'm senseless?
>>
>> let's take that example though a bit further and say we're dealing with
>> php code. if a function has parameters a, b, and c. you probably write it
>> and call it thusly:
>>
>> function foo($a, $b, $c)
>> {
>> return true;
>> }
>>
>
> No, I don't. I write it as
>
> function foo($a, $b, $c) {
> return true;
> }
>
>> i bet though, that when your parameter names are very long and numerous,
>> you either single line them or column-ize them, like this:
>>
>> function foo(
>> $a ,
>> $b ,
>> $c ,
>> ...
>> )
>> {
>> return true;
>> }
>>
>
> Nope. If it all fits in one line on my screen, I put it on one line.
about to bust a gut...gotta hold it in...
> Otherwise I split it into 2 lines, with the second line indented, such as:
WELL HOLY SHIT !!! so you COLUMN-IZE !!! did i not mention that? again, if
screen realestate is your only concern here, then why bother to write php in
any other fashion. it parses the same as sql - spaces stripped and so on?
just one line the whole thing. oh yeah, you DO format...you just don't care
for how I format. not my point or a concern of mine, jerry. argue that till
you're blue in the face. in the end, it's a stylistic issue and to each
their own. just like how you put the body brace on the same line as the
ending parenth of the function rather than on it's own line. :)
i'm not arguing style. again i say, repeat that to yourself until it sinks
in.
> function foo ($a, $b, $c ..... lots more
> $x, $y, $z) {
> return true;
> }
>
> And BTW, if my SQL clause gets too long, I do it the same way.
imagine that!
>> and i bet you do the same when defining arrays, right? ask yourself why.
>> probably because it is more legible and maintainable, right? if the only
>> time you do this is when the function's params are way in the right
>> margin, forcing you to scroll to see them all...essencially screen space,
>> i think i'll but a gut.
>>
>
> Nope. I do arrays similar to the rest.
'nope'? 'similar to the rest'? so, 'nope' is really 'yep' since i suggested
both one-lining params *and* columnizing them...just as you explained you do
in your example above. are you just being disagreeable today? at least
disagree with me! not agreeing with yourself, aside from looking silly, just
isn't profitable for you.
>>>> for the same reasons you should format sql, you format any other
>>>> language you write in. i'm sure you've written lots of scripts that are
>>>> over several hundred lines. why would you approach writing sql any
>>>> differently than other language? just curious jerry. if you have no
>>>> other explanation than what you've stated, you've hardly made a
>>>> case...except a 'special case' which is therefore, a logical fallacy.
>>> I never said you shouldn't format SQL. I said the way you did it is
>>> stupid.
>>
>> wow! i should have gotten 'stupid' from "I don't agree with your
>> method..."? i'm really going to have to read your posts with a lot more
>> inferencing than is normally due any other human being. that is, unless
>> you are saying it is stupid now...as opposed to "i said...".
>>
>
> Well, that's what I think about your formatting method. It wastes all
> kinds of screen space, making it much harder to see the big picture.
hmmm, i've never heard that about my queries before. quite the opposite. as
i'm not averse to screen space usage, it's not a big deal to me. further,
were it, i'd use a code folding editor.
as it is, i couldn't give two rats asses whether you approve of my
formatting. that is NOT what i've been discussing. do you get that yet?
>> likewise, rather than bash the way i format sql, wouldn't it have been
>> more helpful to address the point of FORMATTING sql - which was my point
>> to begin with. further, providing an example of the way YOU format sql
>> would have expanded the topic for the op. hell, i may even side with YOUR
>> version of formatting sql v. the way I format mine. but, simply leaving
>> it at 'your way is stupid, you're an asshole and senseless for
>> disagreeing with me' doesn't really help anyone...or, your cause - which
>> i have yet to figure out here yet.
>>
>
> I did address the point.
no, your point was that you disagree with my method. that could be
formatting or style. since you can't grasp that my point was formatting, it
is easy for you to think you've addressed the point. the only time you
actually glanced the point was when you said you do encourage formatted sql.
fine, discussion over. we agree. as to style? i don't care.
> And I did provide an example. But when you promote poor formatting
> practices, I'll call you on it.
poor in the eyes of jerry stuckle. you objection is saying that it takes up
too much screen space. i've added many descriptives of individual benefits
to my stylization/formatting. you have yet to counter any single one of
them. there's a good debate were you to do so. name calling and slander
('promote poor formatting practices') without a cite to back up the premise
is hardly an engagement at all. are you going to 'recurse' or are you going
to counter? i'm not interested in your current vein...a non-opinionated,
supported counter would be nice about now.
call me on it with fact, jerry. if i want to entagle myself in a stylistic
debate, fact will be my only lure. as it is, we agree on the value of
formatting sql statements. that was my point in all of my responses. get
over it.
>>> But like anyone with no argument, you keep trying to put words into my
>>> mouth.
>>
>> wow jerry, i've been stating MY case. i've not even addressed any of your
>> points. look at your ONE, SINGLE POST in this thread. what POINT (much
>> less points, plural) did you actually make? you said you disagree with
>> me. that's fine. i simply added more reasons for you/anyone to understand
>> why i and others do things the way we do.
>>
>> so please, quote me and the words you are proposing that i'm putting in
>> your mouth.
>>
>
> You stated that I advocated no formatting of the sql statements. That is
> not what I said. Go back and read.
i did.
topic == formatting sql NOT how STEVE formats sql. since the topic was
countered by you originally as 'i don't approve of your method of
formatting', it is logical that that sentence looks incomplete...completed
with 'sql statements'. that means to me, you don't advocate formatting sql.
otherwise, i'd just have said i don't care if anyone approves of how i do
it, just that it is done. and that would have been the end of the
discussion.
you've since described my formatting style as senseless, stupid, and lousy.
good on you! i couldn't care less...nor does anyone else here. at least
those adjectives alerted me to the fact that you didn't get my point, or
didn't want to acknowlege it - formatting sql == good.
>> i hope you are not projecting on me here from some other thread where
>> some other person has bashed you. as you know, i have no beef with you.
>> and throughout this thread in rebuttal with you and darko, i've been
>> unusually polite. hence my puzzlement of being called an asshole,
>> senseless, and stupid. how did i get your ire up so?
>
> No, I'm addressing you and what you said.
not very well. you glanced over my whole point in a frenzy of 'your way of
formatting sql statements blows...but oh yeah, formatting sql is in fact a
good thing to do'. where everything after the elipses is about
font-size:6.25...and subscript at that! formatting sql statements, jerry.
repeat it, rinse, then repeat it again. that's my point. any other tangent
you've brought forth is not a concern of mine as it all revolves around
opinion and stylistic tastes...unless again, you can give cites - however,
you don't seem to want to actually debate...just toss ad-homonyms about.
whatever.
Navigation:
[Reply to this message]
|