From: optimistx on

"Malcolm Dew-Jones" <yf110(a)> kirjoitti
> optimistx (optimistx(a) 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
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,
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

From: wilq on
On Oct 20, 11:35 am, Stevo <n...(a)mail.invalid> wrote:
> optimistx wrote:
> > 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.

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