cluttered code prevention?

O

optimistx

How do you prevent your code looking cluttered?

When there are debugging statements and many kinds of error
checking statements added, the programs start looking
cluttered, difficult to read and comprehed. They do
not resemble nice and elegant school book examples.

If we remove the extra statements and save both versions,
we have two versions to maintain, and they might get
out of sync. (and final removal of debugging statements
might be bad, because later when changing the program
they would be useful to still have).

Have you found a program which would remove the extra
(or 'extra') statements marked with some rule?

Or is there a way to utilize inheritance, prototypes etc to
maintain two (or perhaps more) versions so that one
could see the short version easily, and all the changes would
go naturally where they belong without risk becoming
out of sync?

What do you think?
 
S

Stevo

optimistx said:
How do you prevent your code looking cluttered?

When there are debugging statements and many kinds of error
checking statements added, the programs start looking
cluttered, difficult to read and comprehed. They do
not resemble nice and elegant school book examples.

If we remove the extra statements and save both versions,
we have two versions to maintain, and they might get
out of sync. (and final removal of debugging statements
might be bad, because later when changing the program
they would be useful to still have).

Have you found a program which would remove the extra
(or 'extra') statements marked with some rule?

Or is there a way to utilize inheritance, prototypes etc to
maintain two (or perhaps more) versions so that one
could see the short version easily, and all the changes would
go naturally where they belong without risk becoming
out of sync?
What do you think?

We have some Ant scripts that strip out debug statements. We simply
ensure that all debug statements (and the debug functions they call)
share a common totally unique string (e.g. OptimistixDebug) and the Perl
script strips out the entire lines.

It also helps if you use a syntax-coloring editor like Ultraedit. You
can make the debug code appear in a different color. I have all comments
in a light grey. That makes a huge difference.
 
O

optimistx

Stevo said:
....

We have some Ant scripts that strip out debug statements. We simply
ensure that all debug statements (and the debug functions they call)
share a common totally unique string (e.g. OptimistixDebug) and the
Perl script strips out the entire lines.

It also helps if you use a syntax-coloring editor like Ultraedit. You
can make the debug code appear in a different color. I have all
comments in a light grey. That makes a huge difference.
Your coloring idea seems fascinating, I have to try it soon.

When playing with this after my post yesterday I found code folding
(in Netbeans 6.71.) to be of some help: only function headers are
visible in the folded state and one needs to open those methods with which
one is currently working.

Could one use (prototypal ) inheritance to create short and long versions
of methods? This is like thinking loud :). It would be interesting to see
how it could be done. But also intriguing, why not. Inheritance is
in my understandig just for the cases like this (?), but I cannot see
at first thougth, how to proceed.
 
D

Dr J R Stockton

In comp.lang.javascript message said:
How do you prevent your code looking cluttered?

When there are debugging statements and many kinds of error
checking statements added, the programs start looking
cluttered, difficult to read and comprehed. They do
not resemble nice and elegant school book examples.

Material not currently required can be preceded on its line with, say,
six tabs and "/// ". It can still be seen, but it's out of the flow.
Have you found a program which would remove the extra
(or 'extra') statements marked with some rule?

Personally, I use the published version of my pages, at Demon, as a
backup for the editing machine; so what you see is what I edit.

On a "commercial" basis, the published version can have all leading
whitespace removed (except in PRE), and all lines starting \s*\/\/
removed, and a bit more. I don't do that, but in editing I routinely
remove all trailing whitespace (when first done, that amounted to a few
percent of file size).

Those edits can be done by standard JavaScript running in a local Web
page, with Microsoft extras, except that it would be necessary to do
Select All, Copy, Paste, Save to transfer the reduced version to file.
Or is there a way to utilize inheritance, prototypes etc to
maintain two (or perhaps more) versions so that one
could see the short version easily, and all the changes would
go naturally where they belong without risk becoming
out of sync?

There are source control systems on the market.
 
O

optimistx

Malcolm Dew-Jones said:
optimistx ([email protected]) wrote:
: How do you prevent your code looking cluttered?

Get a bigger monitor. (Not intended as a joke.) Seeing more code ar once
makes it much easier to see how it is organized. Buying a 19" monitor
years ago was one of the best upgrades I made.

That is a very good tip for anyone. In fact so good that I have been using 4
monitors
simultaneously , 2 above, 2 below, many years now. Strange that this has not
been recommended more often. 4 interfaces take so 4 slots in the computer,
but
if there were more slots I would consider 2 more :).
2 of the monitors show the source code, 1 the browser window, 1 for misc
tours to documents, searching etc. Actually 1 more monitor permanently for
firebug would
be nice .
The cost? Practically free when assembled using used crt-monitors, 19-21
inches.
 
W

wilq

We have some Ant scripts that strip out debug statements. We simply
ensure that all debug statements (and the debug functions they call)
share a common totally unique string (e.g. OptimistixDebug) and the Perl
script strips out the entire lines.

It also helps if you use a syntax-coloring editor like Ultraedit. You
can make the debug code appear in a different color. I have all comments
in a light grey. That makes a huge difference.

We do the same in our project and works quite ok.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top