cluttered code prevention?
in [JavaScript]
|
From: optimistx on 20 Oct 2009 04:59 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?
From: Stevo on 20 Oct 2009 05:35 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.
From: optimistx on 21 Oct 2009 01:35 Stevo wrote: > optimistx wrote: >> How do you prevent your code looking cluttered? .... > > 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.
From: Dr J R Stockton on 21 Oct 2009 13:31 In comp.lang.javascript message <4add7be6$0$6279$9b536df3(a)news.fv.fi>, Tue, 20 Oct 2009 11:59:18, optimistx <optimistx(a)hotmail.com> posted: >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. -- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036) Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
From: Malcolm Dew-Jones on 21 Oct 2009 19:08
optimistx (optimistx(a)hotmail.com) 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. I have recently been given two more 19" monitors from people that upgraded to flat screens, and have seen several more being given away after garage sales (they were only $10 or so even during the garage sale). The point is that a large monitor does not have to cost much money. An older video monitor costs more to run than an LED, but that makes little difference unless you are using it continually all day every day (in which case go buy a flat screen large monitor). Find a coding style you like and stick to it. If all your code has the same style then it is much easier to read because your eye can instantly move to the right place for the things in which you are interested. Style includes (among other things) putting the same things in the same places so you always know where they are, that includes small things like whether you put commas at the end of a line or the start of the next line, plus large things like ordering of routines in a file. E.g. some clients insist that routines and variables be arranged alphabetically, which is annoying when they are being developed but quite convenient later on. Personally I use an anti-python indenting for some of my code. When a small bit of code is not finished (i.e. I am not sure it is correct) or it's temporary then I put that at the far left edge (no indent at all). As I decide it is correct and permanent then I move it into position. Meanwhile, it stands out from the correct and finished code, and doesn't break the visual flow of the rest of the program. Once a reviewer asked me why part of an SQL select statement was oddly formatted in a report - I was able to instantly recognize it as an extra clause I had had to use during debugging which should have been removed. Comments can do that in theory, but I doubt he would ever have noticed a comment in the code of the report, just too hard to read, even assuming I remembered to put one in, whereas my intentional bad format of that single item required nothing from me and instantly caught his eye. $0.10 |