Multiple Statements per Line
in [ASM]
|
From: randyhyde@earthlink.net on 7 Apr 2006 12:35 Every now and then, someone around here starts making the claim that having multiple statements per line is good programming style (largely, this comes from the RosAsm camp where that seems to be the standard programming style, but other people have posted such code, too). Multiple statements per line have been possible in programming languages since the days of Algol-60 (at least), yet you *rarely* see this facility employed in readable programs. The lack of such usage should give everyone a big clue that most programmers don't expect to have to read code written in such a fashion. Let's consider what Steve McConnell has to say about this subject in "Code Complete". For those who are unfamiliar with this book, it was first published in 1993 (a second edition appeared last year) and has remained one of the top selling computer science books of all time. It is as close to a universally accepted book on programming style as you could possibly expect to find (particularly given the wide diversity of opinions on the subject of programming style). Steve achieves this "universality" largely by presenting all the possible options for one give style and discusses the strengths and weaknesses of both sides of the argument and then leaves it largely up to the reader to decide between the two, unless there is a very compelling reason to say "don't do this" or "you should do that". Here's what Steve as to say about multi-statement source lines (and there is *little* controversy in what he has to say here, I might point out). >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Using Only One Statement per Line --------------------------------------------------- Modern language such as Pascal, C, and Ada allow multiple statements per line. Free formatting is a big improvement over Fortran's requirement that comments begin in column one and statements begin in column 7 or later. The power of free formatting is a mixed blessing, however, when it comes to putting multiple statements on a line: i=0; j=0; k=0; DestroyBadLoopNames( i, j, k ); This line contains several statements that could logically be separated onto lines of their own. One argument in favor of putting several statements on one line is that it requires fewer lines of screen space or printer paper, which allows more of the code to be viewed at once. It's also a way to group related statements, and some programmers believe that it provides optimization clues to the compiler. These are good reasons, but the reasons to limit yourself to one statement per line are more compelling: * Putting each statement on a line of it's own provides an accurate view of a program's complexity. It doesn't hide complexity by making complex statements look trivial. Statements that are complex look complex. Statements that are easy, look easy. * Putting several statements on one line doesn't provide optimization clues to modern compilers. Today's optimizing compilers don't depend on formatting clues to do their optimizations. This is illustrated later in this section. * With statements on their own lines, the code reads from top to bottom, instead of top to bottom and left to right. When you're looking for a specific line of code, your eye should be able to follow the left margin of the code. It shouldn't have to dip into each and every line just because a single line might contain two statements. * With statements on their own lines, it's easy to find syntax errors when your compiler provides only the line numbers of the errors. If you have multiple statements on a line, the line number doesn't tell you which statement is in error. * With one statement to a line, it's easy to step through the code with line-oriented debuggers [e.g., symbolic debuggers, RLH]. If you have several statements on a line, the debugger executes them all at once, and you have to switch to assembler [machine code, RLH] to step through individual statements. * With one to a line, it's easy to edit individual statements -- to delete a line or temporarily convert a line to a comment. If you have multiple statements on a line, you have to do you editing between other statements. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Some additional comments: Programmers who've learned their craft in the past 15 years may not understand why someone would think that putting multiple statements on a single line produces more optimal code. However, those who grew up programming in microcomputer BASIC in the late 1970's and 1980's understand what this comment is about. Back then, programs *did* run faster if you crammed multiple statements per line. Of course, this doesn't apply to modern compilers and certainly not to assembly code, but the explanation is important for historical reasons. One argument that Steve gives, which is the same argument people around here are using, for putting multiple statements per line (MSPL) is that it groups related statements together (which is a good thing). However, you can achieve the same effect, without the bad side-effects of MSPL by using blank lines to separate sequences of unrelated blocks of statements. And using blank lines is *far* more consistent. After all, there are going to be *some* groups of statements that you could not place all on one line. So you're going to have to use some other scheme (such as blank lines) to organize such statements, anyway. Better to be consistent and use a *single* scheme in the source file to group your statements rather than having rules that apply in some circumstances and not in others (and other big no-no that Steve points out when discussing programming style conventions). The comment about debuggers needs to be amplified. Steve talks about dropping down into "assembly" language. Obviously, that statement wouldn't apply as we're already working in assembly language. However, Steve doesn't really mean "assembly", he means *machine code*. That is, if your assembler supports multiple statements per line and your debugger lets you set breakpoints based on lines of source code (as most do), then you've still got the problem in assembly language and you'll have to drop down into machine code to set the breakpoints on an inter-statement/intra-line basis. Granted, this isn't as much of a pain as it would be when working in a HLL (where the programmer may not even understand the machine code), but it's still an issue. I would make one final observation about cramming multiple statements per physical source line. If you're doing this in order to logically group a sequence of statements together (that is, you're creating an abstraction of those individual statements), then perhaps it's time to refactor your code. Create a procedure or a macro that does the intended operation. Invoke that procedure or macro rather than cramming all those statements on the same line. You'll find that the code is *far* more readable at that point, and you'll also start to discover patterns in your code where you're doing the same sort of things over and over again. And as Hunt & Thomas point out in "The Pragmattic Programmer": DRY (Don't Repeat Yourself). If you find that you're coding the same patterns over and over again, abstract those patterns (i.e., create a procedure/function/macro implementation). The result will be far more readable and maintainable. Cheers, Randy Hyde P.S. "Code Complete" and "The Pragmatic Programmer" are *required* reading for anyone who fancies themselves to be a computer programmer.
From: JGCASEY on 7 Apr 2006 14:49 randyhyde(a)earthlink.net wrote: > Every now and then, someone around here starts > making the claim that having multiple statements > per line is good programming style (largely, > this comes from the RosAsm camp where that seems > to be the standard programming style, but other > people have posted such code, too). Everyone has their own idea of "good programming style" or perhaps I should write, "what works for them". As you can see from my posts I like short lines, seven to eight words per line I find the most comfortable to read. But that is me, I don't claim everyone has this problem. I like visual descriptions, perhaps those who prefer written descriptions would long lines easier to read? > * With statements on their own lines, it's easy > to find syntax errors when your compiler provides > only the line numbers of the errors. If you have > multiple statements on a line, the line number > doesn't tell you which statement is in error. There is no reason why the line number *and* the position within the line cannot be given. A Hll with multiple statements per line would or should have this feature. At the risk of incurring the wrath of Rene I have to say, that with my limited experience of reading other people's code, I personally find code written with the principles you have given easier to read. One thing I never liked about C and the other languages that use the curly brackets { and } is that visually the blocks of code did not pop out for me without practice and even today some effort despite indentation. Or maybe I am just visually handicapped in some way which is why I have a problem with multiple statements per line? -- JC
From: Betov on 7 Apr 2006 15:06 "JGCASEY" <jgkjcasey(a)yahoo.com.au> ?crivait news:1144435777.605385.53030 @i40g2000cwc.googlegroups.com: > [...] Why on earth do you answer to some "Steve McConnell" who wrote some "book" (???!!!...), before 1993, and who is not there? After all, maybe _some_ of his arguments could have been considered (i mean not as stupid as for not even diserving any answer)... before 1993, but who cares of a "Book Writer" opinions, at the end? I have to point you to the fact that i never talked about opinions, that i gave technical arguments -when answering to James-, and that, up to now, there was, exactly, zero counter-argument. Betov. < http://rosasm.org >
From: randyhyde@earthlink.net on 7 Apr 2006 15:20 Betov wrote: > "JGCASEY" <jgkjcasey(a)yahoo.com.au> écrivait news:1144435777.605385.53030 > @i40g2000cwc.googlegroups.com: > > > [...] > > Why on earth do you answer to some "Steve McConnell" who > wrote some "book" (???!!!...), before 1993, and who is > not there? Second Edition appeared last year. > > After all, maybe _some_ of his arguments could have been > considered (i mean not as stupid as for not even diserving > any answer)... before 1993, but who cares of a "Book Writer" > opinions, at the end? Apparently a lot of people care. Because it's one of the top-selling compsci books of all time. Cheers, Randy Hyde
From: randyhyde@earthlink.net on 7 Apr 2006 15:40
JGCASEY wrote: > randyhyde(a)earthlink.net wrote: > > Every now and then, someone around here starts > > making the claim that having multiple statements > > per line is good programming style (largely, > > this comes from the RosAsm camp where that seems > > to be the standard programming style, but other > > people have posted such code, too). > > > Everyone has their own idea of "good programming > style" or perhaps I should write, "what works for > them". Again, remember the matra for readable code: "You write readable code for OTHER people, not for yourself." If no one other than yourself ever reads your code, the readability is irrelevant. You can write the code however you like. Heck, put the whole program on one source line if you like (a common mistake APL programmers made, for example; pretty much ensuring that only the original author ever read the code). Readability is only important if *other* people are going to read your code. What that's important, it's important that you write your code in a manner that *they* find easy to read. If you want to be known for writing readable code, then you have to adopt a programming style other the typical programmer expects; you cannot expect them to adopt to your style. > As you can see from my posts I like short > lines, seven to eight words per line I find the > most comfortable to read. But that is me, I don't > claim everyone has this problem. Actually, *most* people read faster, and with better comprehension, when working with short lines (though this is not an argument for manually insert line breaks everywhere; almost any decent newsreader is going to allow someone to adjust the width to their liking). > > I like visual descriptions, perhaps those who > prefer written descriptions would long lines > easier to read? Clearly, visual images (as opposed to text) are better for most people. Alas, programming languages tend to be tied down to the ASCII character set (not all, but most). We have to work with what we've got, unfortunately. Allow me to give an example. The editor I personally prefer (Borland's CodeWright) allows me to insert JPEG and other images directly into my source file (as comments) and display those in the editor. This is a really cool feature for documenting the program. Alas, only CodeWright owners can take advantage of this facility. So I don't use it because other people who don't own CodeWright can't see my nice diagrams. > > > > > * With statements on their own lines, it's easy > > to find syntax errors when your compiler provides > > only the line numbers of the errors. If you have > > multiple statements on a line, the line number > > doesn't tell you which statement is in error. > > > There is no reason why the line number *and* the > position within the line cannot be given. A Hll > with multiple statements per line would or should > have this feature. Perhaps it should. That doesn't mean that it does. And if you're moving code between compilers, there is no guarantee that the next compiler you're using supports the feature even if the previous one does. OTOH, this certainly isn't the primary reason I'd be concerned about multiple statements per line. After all, once the syntax errors are all eliminated, this is no longer an issue. But the other readability issues remain. A similar argument could be made about the importance of single statement lines in a debugger (once the bugs are gone, who cares? But you've still got to read the code). > > At the risk of incurring the wrath of Rene I have > to say, that with my limited experience of reading > other people's code, I personally find code written > with the principles you have given easier to read. Well, I *have* studied the subject to a fair extent (e.g., I've taught software engineering classes at UC Riverside and Cal Poly Pomona; one would *hope* I've done a little reading on the subject). > > One thing I never liked about C and the other > languages that use the curly brackets { and } is > that visually the blocks of code did not pop out > for me without practice and even today some effort > despite indentation. > > Or maybe I am just visually handicapped in some way > which is why I have a problem with multiple statements > per line? Let's be clear on one thing. I am not saying that there is no one on this planet who won't find multiple statements per line to be more readable than putting them all on separate lines (at least, in certain circumstances). Human beings are quite adaptable and can often convince themselves that something is better when, in fact, it really isn't. Or maybe they can, with concerted effort, learn something so well that it really *is* better for them to see material presented in some particular format. If you're arguing that *you* might find some sequences easier to read if someone stuck multiple statements together on one line, who am I to argue with that? What I *am* saying, however, is that if you write code in this manner, because it's easier for you to read it that way, then the vast majority of the programmers out in the real world are going to have (more) difficulty reading your code than they otherwise would have. And the reason for that (beyond the fact that it's not something they're used to seeing) is summed up by McConnell's statement about reading top to bottom and left to right. Everything else is just a supporting role. It's the intertwining of the left->right and top->bottom that is the real problem. Cheers, Randy Hyde |