Mangled Code Mess

[Tim Streater]

Re: Mangled Code Mess

In article <mhhgh.21433$f1 5.7579@fe09.use netserver.com>,
Double Echo <doubleecho@you r.comwrote:

It might be easier for _you_, but not for the next poor bastard that will
have to agonize at the shitmess you made.

My code is carefully laid out, thank you.

There is no excuse for shitty-looking code. Another annoyance for me are
people
who have to roll-up their brackets as if there is a line penalty for good,
structured
code. Like you're going to run out of lines or air or something.
>
People who like to
>
if (...) {
}
>
or
>
while(...) {
}
>
annoy the fuck-out-of-me because I have to stop, read really slowly and try
to grasp
the nesting, and logic. It's all rolled up so you can't hardly separate the
code into
something readable.
>
It's so much cleaner to
>
if ( ... )
{
code here
}
>
or
>
while( ... )
{
code here
}

Funnily enough I completely agree here. If the braces are lined up then
matching braces are so much easier to find.

but all the goddam schools preach shitmess roll-up coding and OO. It works
but it's so fucking
messy. You fucking kids think it's cool code, and wow, neato, but then
somebody else has to
work on it, and it's a fucking nightmare. Clean code, nested, and properly
written will allow
the code to be debugged better, and probably survive being re-written all
over again because you
can actually read it. I've gone on to delete code I can't read and just
re-wrote it cleanly.

When what you are dealing with is spaghetti this may well be necessary.

-- tim

[Tim Streater]

Re: Mangled Code Mess

In article <fbednSbHwaH_IB zYnZ2dnUVZ_ryln Z2d@comcast.com >,
Jerry Stuckle <jstucklex@attg lobal.netwrote:

Double Echo wrote:

[...]

>

but all the goddam schools preach shitmess roll-up coding and OO. It
works but it's so fucking
messy. You fucking kids think it's cool code, and wow, neato, but then
somebody else has to
work on it, and it's a fucking nightmare. Clean code, nested, and
properly written will allow
the code to be debugged better, and probably survive being re-written
all over again because you
can actually read it. I've gone on to delete code I can't read and just
re-wrote it cleanly.

-DE- ( using my best Dr. House imitation )

>
Well, if "all the goddam schools" teach it, there must be something to
it, don't you think?

It's just the vogue at the moment. Those of us who have developed a
coding style over 40 years to assist maintainers who might be following,
think different. Cool is not important - maintainability is (and
donkeymentation , of course).

Personally I dislike something like:

if (send_packet(pa rams)) {
do something
}

not just because of the braces but also because an "if" is supposed to
perform a test - not have as a side effect as it might be sending a
packet over the wire.

-- tim

[Jerry Stuckle]

Re: Mangled Code Mess

Tim Streater wrote:

In article <fbednSbHwaH_IB zYnZ2dnUVZ_ryln Z2d@comcast.com >,
Jerry Stuckle <jstucklex@attg lobal.netwrote:
>
>

>>Double Echo wrote:

>
>
[...]
>
>

>>>but all the goddam schools preach shitmess roll-up coding and OO. It
>>>works but it's so fucking
>>>messy. You fucking kids think it's cool code, and wow, neato, but then
>>>somebody else has to
>>>work on it, and it's a fucking nightmare. Clean code, nested, and
>>>properly written will allow
>>>the code to be debugged better, and probably survive being re-written
>>>all over again because you
>>>can actually read it. I've gone on to delete code I can't read and just
>>>re-wrote it cleanly.
>>>
>>>-DE- ( using my best Dr. House imitation )
>>>
>>>

>>
>>Well, if "all the goddam schools" teach it, there must be something to
>>it, don't you think?

>
>
It's just the vogue at the moment. Those of us who have developed a
coding style over 40 years to assist maintainers who might be following,
think different. Cool is not important - maintainability is (and
donkeymentation , of course).
>

In your opinion, at least. Many others, including us who have been
programming 39 years (started with Fortran II on an IBM 1401) think
differently.

Some old-time programmers get so ingrained in one method it's hard for
them to see a different way of doing things might be better. Others
find new ways to be much better - including easier to maintain.

It's a matter of style.

Personally I dislike something like:
>
if (send_packet(pa rams)) {
do something
}
>
not just because of the braces but also because an "if" is supposed to
perform a test - not have as a side effect as it might be sending a
packet over the wire.
>
-- tim

I love it, and use it all the time. First started doing in in C over 20
years ago. It's one of the great features of languages like C, C++,
Java and PHP, and allows for a lot of flexibility.

In your case the if statement is doing a test - but it's just a test to
see if an action (a dynamic event) completed successfully, instead of
the static value of a variable.

Let's take it one step further:

result = send_packet(par ams);
while (result) {
do something
result = send_packet(par ams);
}

Or, just

while (send_packet(pa rams)) {
do something
}

After all, all a while loop is is a test which is executed repeatedly
until the condition fails.


--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Tim Streater]

Re: Mangled Code Mess

In article <NtqdneCPLbONNB _YnZ2dnUVZ_smon Z2d@comcast.com >,
Jerry Stuckle <jstucklex@attg lobal.netwrote:

Tim Streater wrote:

[...]

It's just the vogue at the moment. Those of us who have developed a
coding style over 40 years to assist maintainers who might be following,
think different. Cool is not important - maintainability is (and
donkeymentation , of course).

>
In your opinion, at least. Many others, including us who have been
programming 39 years (started with Fortran II on an IBM 1401) think
differently.
>
Some old-time programmers get so ingrained in one method it's hard for
them to see a different way of doing things might be better. Others
find new ways to be much better - including easier to maintain.

I think it's just a vogue. Like when Pascal was the vogue and it was
considered "good" to have only one exit from a procedure. As
excruciating contortions were needed in real-world code to achieve this,
I carried right on using the return statement and ignored the vogue.

Personally I dislike something like:

if (send_packet(pa rams)) {
do something
}

not just because of the braces but also because an "if" is supposed to
perform a test - not have as a side effect as it might be sending a
packet over the wire.

>
I love it, and use it all the time. First started doing in in C over 20
years ago. It's one of the great features of languages like C, C++,
Java and PHP, and allows for a lot of flexibility.
>
In your case the if statement is doing a test - but it's just a test to
see if an action (a dynamic event) completed successfully, instead of
the static value of a variable.
>
Let's take it one step further:
>
result = send_packet(par ams);
while (result) {
do something
result = send_packet(par ams);
}
>
Or, just
>
while (send_packet(pa rams)) {
do something
}
>
After all, all a while loop is is a test which is executed repeatedly
until the condition fails.

If you're doing a test, do a test. If you're sending a packet, send a
packet. These are distinct actions that should be separated.

That's my style, at any rate.

-- tim

[bill]

Re: Mangled Code Mess

Double Echo wrote:

Bill,
>
Sorry for not getting back sooner... had a lot of work interrupting my
newsgroup time. :-)
>
Here-doc allows you to basically print out whatever is between the
pattern you choose.
>
I use ENDOFHTML but you could use ENDOFCODE or whatever.
>
Perl has a similar construct:
>
print <<ENDOFHTML;
ENDOFHTML
>
Notice the semi-colon at the top, PHP is a bit more "correct" putting
the semi-colon at
the end:
>
print <<<ENDOFHTML
ENDOFHTML;
>
PHP also uses "<<<" whereas Perl uses "<<".
>
Anyway, embedded PHP programs were the rave a couple of years ago, and
people were doing
it trying to create really dynamic pages, but it's really messy as
you've found out to do it that way.
It's easier to print <<<EDNDOFHTML because you can actually use ' and "
in the block without trouble. There are also a lot of web servers that
don't like embedded
PHP in HTML docs and will barf or ignore it if you attempt it. So, it's
better to embed HTML in PHP,
and save yourself the hassle. One note, be careful about the placement
at the end, the
end tag _must_ be over at the left, and no space after it, or it won't
work.
>

THank you. I like to embed the html in the php, but having to
escape all the quotes was killing me - this is much nicer.
bill

>
>
bill wrote:

>see end of post:
>>
>Double Echo wrote:

>>This is old-style dirty PHP programming. There are a lot of stupid
>>programmers
>>who mingle/mangle code like this trying to be cute. Instead of some
>>HTML
>>with PHP thrown in, reverse it. Have PHP with HTML thrown in. PHP
>>should be the control, HTML should not be.
>>>
>><?php
>>>
>>$var = 1 + 1 ;
>>>
>>print <<<ENDOFHTML
>><html>
>><table>
>><tr>
>><td>
>>$var
>></td>
>></tr>
>></table>
>>>
>>ENDOFHTML;
>>>
>>$some_more_ph p = 2 + 2 ;
>>>
>>print <<<ENDOFHTML
>>$some_more_ph p
>>ENDOFHMTL;
>>>
>>?>
>>>
>>A lot of web servers won't be set up for HTML-with-PHP but if you have
>>a web server with PHP enabled, you can always throw in HTML.
>>Programmers
>>who mix PHP into HTML just don't know how to program cleanly.
>>>
>>-DE-
>>>

>DE.
>for a newbie, who likes your style, please reference or explain the
>syntax:
>>
>print <<<ENDOFHTML
>>
>bill

>

[Jerry Stuckle]

Re: Mangled Code Mess

Tim Streater wrote:

In article <NtqdneCPLbONNB _YnZ2dnUVZ_smon Z2d@comcast.com >,
Jerry Stuckle <jstucklex@attg lobal.netwrote:
>
>

>>Tim Streater wrote:

>
>
[...]
>
>

>>>It's just the vogue at the moment. Those of us who have developed a
>>>coding style over 40 years to assist maintainers who might be following,
>>>think different. Cool is not important - maintainability is (and
>>>donkeymentat ion, of course).
>>>

>>
>>In your opinion, at least. Many others, including us who have been
>>programming 39 years (started with Fortran II on an IBM 1401) think
>>differently .
>>
>>Some old-time programmers get so ingrained in one method it's hard for
>>them to see a different way of doing things might be better. Others
>>find new ways to be much better - including easier to maintain.

>
>
I think it's just a vogue. Like when Pascal was the vogue and it was
considered "good" to have only one exit from a procedure. As
excruciating contortions were needed in real-world code to achieve this,
I carried right on using the return statement and ignored the vogue.
>

As I say - in your opinion. Millions of programmers disagree with you.

>

>>>Personally I dislike something like:
>>>
>>>if (send_packet(pa rams)) {
>> do something
>>>}
>>>
>>>not just because of the braces but also because an "if" is supposed to
>>>perform a test - not have as a side effect as it might be sending a
>>>packet over the wire.

>>
>>I love it, and use it all the time. First started doing in in C over 20
>>years ago. It's one of the great features of languages like C, C++,
>>Java and PHP, and allows for a lot of flexibility.
>>
>>In your case the if statement is doing a test - but it's just a test to
>>see if an action (a dynamic event) completed successfully, instead of
>>the static value of a variable.
>>
>>Let's take it one step further:
>>
>>result = send_packet(par ams);
>>while (result) {
> do something
> result = send_packet(par ams);
>>}
>>
>>Or, just
>>
>>while (send_packet(pa rams)) {
> do something
>>}
>>
>>After all, all a while loop is is a test which is executed repeatedly
>>until the condition fails.

>
>
If you're doing a test, do a test. If you're sending a packet, send a
packet. These are distinct actions that should be separated.
>
That's my style, at any rate.
>
-- tim

Why? When it makes the code more complicated and harder to understand?

It is a test - a test as to whether the action completed successfully or
not. But this concept is harder for some old-time programmers to grasp.

Just like in my classes - COBOL and FORTRAN programmers had a lot harder
time grasping the concept of pointers as implemented in C than new
programmers did.

And typically the longer someone had been doing structured programming,
the more trouble he/she had in grasping OO concepts.

It's sometimes hard for old-time programmers to change their habits.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Double Echo]

Re: Mangled Code Mess

Jerry Stuckle wrote:

Tim Streater wrote:

>In article <NtqdneCPLbONNB _YnZ2dnUVZ_smon Z2d@comcast.com >,
> Jerry Stuckle <jstucklex@attg lobal.netwrote:
>>
>>

>>Tim Streater wrote:

>>
>>
>[...]
>>
>>

>>>It's just the vogue at the moment. Those of us who have developed a
>>>coding style over 40 years to assist maintainers who might be
>>>following, think different. Cool is not important - maintainability
>>>is (and donkeymentation , of course).
>>>>
>>>
>>In your opinion, at least. Many others, including us who have been
>>programming 39 years (started with Fortran II on an IBM 1401) think
>>differently .
>>>
>>Some old-time programmers get so ingrained in one method it's hard
>>for them to see a different way of doing things might be better.
>>Others find new ways to be much better - including easier to maintain.

>>
>>
>I think it's just a vogue. Like when Pascal was the vogue and it was
>considered "good" to have only one exit from a procedure. As
>excruciating contortions were needed in real-world code to achieve
>this, I carried right on using the return statement and ignored the
>vogue.
>>

>
As I say - in your opinion. Millions of programmers disagree with you.
>

>>

>>>Personally I dislike something like:
>>>>
>>>if (send_packet(pa rams)) {
>>> do something
>>>}
>>>>
>>>not just because of the braces but also because an "if" is supposed
>>>to perform a test - not have as a side effect as it might be sending
>>>a packet over the wire.
>>>
>>I love it, and use it all the time. First started doing in in C over
>>20 years ago. It's one of the great features of languages like C,
>>C++, Java and PHP, and allows for a lot of flexibility.
>>>
>>In your case the if statement is doing a test - but it's just a test
>>to see if an action (a dynamic event) completed successfully, instead
>>of the static value of a variable.
>>>
>>Let's take it one step further:
>>>
>>result = send_packet(par ams);
>>while (result) {
>> do something
>> result = send_packet(par ams);
>>}
>>>
>>Or, just
>>>
>>while (send_packet(pa rams)) {
>> do something
>>}
>>>
>>After all, all a while loop is is a test which is executed repeatedly
>>until the condition fails.

>>
>>
>If you're doing a test, do a test. If you're sending a packet, send a
>packet. These are distinct actions that should be separated.
>>
>That's my style, at any rate.
>>
>-- tim

>
Why? When it makes the code more complicated and harder to understand?
>
It is a test - a test as to whether the action completed successfully or
not. But this concept is harder for some old-time programmers to grasp.
>
Just like in my classes - COBOL and FORTRAN programmers had a lot harder
time grasping the concept of pointers as implemented in C than new
programmers did.
>
And typically the longer someone had been doing structured programming,
the more trouble he/she had in grasping OO concepts.
>
It's sometimes hard for old-time programmers to change their habits.
>

I don't know about age being a true component of the argument, it's more
about brain function, some people need object orientated stuff, some don't,
and sometimes it's better to have just the objects you need and the rest
of the app is simply functions. Whatever the need is, not necessarily all
or nothing, this way or that. Sometimes the best of both is really what's
needed. But to suggest that OO is more difficult for old programmers who
do structured programming is a false argument. Most programmers that are
any good have a profit motive and are extremely lazy, so they're going to
do the most efficient thing possible. If I can accomplish an app without
OO you can darn well bet I'll do it without OO unless it's avoidable. It's
like a shotgun for killing mosquitos. On the other hand if I'm part of a
large team and we need the app to have as much components as possible to
build on for the future, OO might be right, but you can still do large
projects without OO. It's a nice feature of PHP to be able to do it
either way. And keep in mind, unless you compile the objects they still
have to be interpreted, and in an interpreted language, speed is everything.
Your OO may actually be too complex and slow the app down, something to
watch for.

Happy Holidays!

:-)

[Jerry Stuckle]

Re: Mangled Code Mess

Double Echo wrote:

Jerry Stuckle wrote:
>

>Tim Streater wrote:
>>

>>In article <NtqdneCPLbONNB _YnZ2dnUVZ_smon Z2d@comcast.com >,
>> Jerry Stuckle <jstucklex@attg lobal.netwrote:
>>>
>>>
>>>Tim Streater wrote:
>>>
>>>
>>>
>>[...]
>>>
>>>
>>>>It's just the vogue at the moment. Those of us who have developed a
>>>>coding style over 40 years to assist maintainers who might be
>>>>following , think different. Cool is not important - maintainability
>>>>is (and donkeymentation , of course).
>>>>>
>>>>
>>>In your opinion, at least. Many others, including us who have been
>>>programmin g 39 years (started with Fortran II on an IBM 1401) think
>>>differentl y.
>>>>
>>>Some old-time programmers get so ingrained in one method it's hard
>>>for them to see a different way of doing things might be better.
>>>Others find new ways to be much better - including easier to maintain.
>>>
>>>
>>>
>>I think it's just a vogue. Like when Pascal was the vogue and it was
>>considered "good" to have only one exit from a procedure. As
>>excruciatin g contortions were needed in real-world code to achieve
>>this, I carried right on using the return statement and ignored the
>>vogue.
>>>

>>
>As I say - in your opinion. Millions of programmers disagree with you.
>>

>>>
>>>>Personall y I dislike something like:
>>>>>
>>>>if (send_packet(pa rams)) {
>>>> do something
>>>>}
>>>>>
>>>>not just because of the braces but also because an "if" is supposed
>>>>to perform a test - not have as a side effect as it might be
>>>>sending a packet over the wire.
>>>>
>>>>
>>>I love it, and use it all the time. First started doing in in C
>>>over 20 years ago. It's one of the great features of languages like
>>>C, C++, Java and PHP, and allows for a lot of flexibility.
>>>>
>>>In your case the if statement is doing a test - but it's just a test
>>>to see if an action (a dynamic event) completed successfully,
>>>instead of the static value of a variable.
>>>>
>>>Let's take it one step further:
>>>>
>>>result = send_packet(par ams);
>>>while (result) {
>>> do something
>>> result = send_packet(par ams);
>>>}
>>>>
>>>Or, just
>>>>
>>>while (send_packet(pa rams)) {
>>> do something
>>>}
>>>>
>>>After all, all a while loop is is a test which is executed
>>>repeatedly until the condition fails.
>>>
>>>
>>>
>>If you're doing a test, do a test. If you're sending a packet, send a
>>packet. These are distinct actions that should be separated.
>>>
>>That's my style, at any rate.
>>>
>>-- tim

>>
>>
>Why? When it makes the code more complicated and harder to understand?
>>
>It is a test - a test as to whether the action completed successfully
>or not. But this concept is harder for some old-time programmers to
>grasp.
>>
>Just like in my classes - COBOL and FORTRAN programmers had a lot
>harder time grasping the concept of pointers as implemented in C than
>new programmers did.
>>
>And typically the longer someone had been doing structured
>programming, the more trouble he/she had in grasping OO concepts.
>>
>It's sometimes hard for old-time programmers to change their habits.
>>

>
I don't know about age being a true component of the argument, it's more
about brain function, some people need object orientated stuff, some don't,
and sometimes it's better to have just the objects you need and the rest
of the app is simply functions. Whatever the need is, not necessarily all
or nothing, this way or that. Sometimes the best of both is really what's
needed. But to suggest that OO is more difficult for old programmers who
do structured programming is a false argument. Most programmers that are
any good have a profit motive and are extremely lazy, so they're going to
do the most efficient thing possible. If I can accomplish an app without
OO you can darn well bet I'll do it without OO unless it's avoidable. It's
like a shotgun for killing mosquitos. On the other hand if I'm part of a
large team and we need the app to have as much components as possible to
build on for the future, OO might be right, but you can still do large
projects without OO. It's a nice feature of PHP to be able to do it
either way. And keep in mind, unless you compile the objects they still
have to be interpreted, and in an interpreted language, speed is
everything.
Your OO may actually be too complex and slow the app down, something to
watch for.
>

First of all, by "old time programmers" I don't necessarily mean age
wise. But I think you have to admit there aren't many 20-something
programmers around who have been programming since 1967, like I have :-)

As for the OO concepts, I have 16 years of corporate training experience
to fall back on. During that time I've trained thousands of
programmers, many in OO languages.

One thing which I've seen repeatedly is the more experienced the
programmer, the harder he/she has adjusting to new concepts.

For instance, COBOL programmers with several years of experience have a
lot of trouble adjusting to the concept of a pointer variable in C/C++.
The same is true with experienced FORTRAN programmers. That's
because those languages don't have pointers.

OTOH, COBOL or FORTRAN programmers with 1-2 years of experience have
less trouble adjusting to pointer data types because they don't have the
preconceived ideas.

The same is true for OO techniques. I didn't say it is more difficult
to learn - but rather it is more difficult for them to overcome
preconceived ideas.

Now I never said OO was right for every circumstance. And I never said
that you had to use OO in every project. But I did say older
programmers have a hard time changing their way of thinking. I stand by
that statement, and so do all of the other OO instructors I know.

Happy Holidays!
>
:-)
>
>

You, too!


--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Tim Streater]

Re: Mangled Code Mess

In article <bPidnYclbqY10B 7YnZ2dnUVZ_u63n Z2d@comcast.com >,
Jerry Stuckle <jstucklex@attg lobal.netwrote:

Tim Streater wrote:

[...]

If you're doing a test, do a test. If you're sending a packet, send a
packet. These are distinct actions that should be separated.

That's my style, at any rate.

-- tim

>
Why? When it makes the code more complicated and harder to understand?

Easier is the word you're looking for. Obviously a typo on your part :-)

It is a test - a test as to whether the action completed successfully or
not. But this concept is harder for some old-time programmers to grasp.

But the test has side-effects. That is my point.

Just like in my classes - COBOL and FORTRAN programmers had a lot harder
time grasping the concept of pointers as implemented in C than new
programmers did.

Never did Cobol, thank goodness. Haven't touched Fortran since 1978.
Since then its been BCPL, C (in large quantities), Z80 assm, and PHP and
JavaScript more recently.

-- tim

[Jerry Stuckle]

Re: Mangled Code Mess

Tim Streater wrote:

In article <bPidnYclbqY10B 7YnZ2dnUVZ_u63n Z2d@comcast.com >,
Jerry Stuckle <jstucklex@attg lobal.netwrote:
>
>

>>Tim Streater wrote:

>
>
[...]
>
>

>>>If you're doing a test, do a test. If you're sending a packet, send a
>>>packet. These are distinct actions that should be separated.
>>>
>>>That's my style, at any rate.
>>>
>>>-- tim

>>
>>Why? When it makes the code more complicated and harder to understand?

>
>
Easier is the word you're looking for. Obviously a typo on your part :-)
>

Nope, I meant exactly what I wrote.

>

>>It is a test - a test as to whether the action completed successfully or
>>not. But this concept is harder for some old-time programmers to grasp.

>
>
But the test has side-effects. That is my point.
>

So? There is absolutely nothing wrong with that. You're testing the
results of a dynamic action, not a static value.

>

>>Just like in my classes - COBOL and FORTRAN programmers had a lot harder
>>time grasping the concept of pointers as implemented in C than new
>>programmers did.

>
>
Never did Cobol, thank goodness. Haven't touched Fortran since 1978.
Since then its been BCPL, C (in large quantities), Z80 assm, and PHP and
JavaScript more recently.
>
-- tim

I'm surprised you didn't run into a lot of this in your C coding.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===