Multiple Statements per Line
in [ASM]
|
From: Betov on 7 Apr 2006 15:48 "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> ?crivait news:1144438838.681127.185530(a)z34g2000cwc.googlegroups.com: > Again, remember the matra for readable code... Ohoh!... The famous author of the most absurd HLL Pre-Parser, ever seen, is talking... :] Betov. < http://rosasm.org >
From: James Daughtry on 7 Apr 2006 15:49 I can't speak for anyone else, so this is pretending that your post is directed at me and not "people who don't get it" in general. I really do appreciate your enthusiasm, so please don't take this the wrong way. But, even if you didn't intend for it to be, your post is dripping with condescension. You assume that anyone who advocates anything but a single statement per line hasn't read Code Complete or The Pragmatic Programmer and you tailor the rest of your post to the assumption that we're all ignorant students of yours that can't comprehend the wonderful things you're trying to explain. Well, Randy, I'm not one of your students. I've read Code Complete (and The Pragmatic Programmer) several times, cover to cover, and taken the time to understand the reasoning behind each option. On top of that, I've done a *lot* of research into readability and good programming style that's taken me well beyond the beaten path. It's not that I don't "get it". You're trying to explain something to me that I already know (as well as you, possibly even better), in a way that makes you come off as an arrogant prick. Here's why: > 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). This is the impression I got from your opening paragraph: Every now and then, some dumbass shows up spouting nonsense about style that I know is wrong. Usually it's Betov and his minions, but occasionally someone who fancies himself a computer programmer tries to make life hard for us "real" computer programmers by "thinking outside the box" and coming up with something the smart people have proven to be bad. I'm going to write a long article explaining exactly why I'm right and everyone else is wrong by quoting from a book and making comments on it. The book is well respected, so in turn, my approving comments of the book should also be respected. Even without my blatantly sarcastic translation, your opening paragraph sounds a lot like you're stroking your ego by putting down people who don't completely agree with you. Now, as expected since you're using a very good book as reference material, you make some good points: > 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). I think you're exaggerating. It seems like you're under the assumption that MSPL (unnecessary acronym?) are used as a complete replacement for other methods of logical grouping and that statements are "crammed" together all willy nilly. That's not the case when MSPL is used correctly, and exaggerating the truth into your own version so that your arguments make more sense is deceptive. As for a single scheme, how do you explain that any good code will use both blank lines *and* indention for logical grouping? That's not as much the case with traditional assembly formatting, but I find that style difficult to read after it gets to a certain length. I'm familiar with the syntax, so ignorance of the language clearly isn't my problem in this case. ;-) Unless you want to claim that I have to have a certain amount of experience reading assembly programs before I'm allowed to have an opinion on readability. > 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. Well, in theory this sounds good, but let's consider the '<test> <jump>' MSPL idea. Sure, you could factor that into a subroutine...hmm, or not, because that's the epitome of silliness. A macro could work, but you would need to pass the label as an argument. You would also need to pass the test as an argument as well, or write multiple macros that do different tests. Wait, why even bother? Oh, right, so you don't repeat yourself. O_o The fact of the matter is that where MSPL works, refactoring doesn't. It's either impractical or illogical. Often, where MSPL works, blank lines don't help readability quite as much, in my opinion (even though it's close). Blank lines and MSPL are simply two tools that you can use. You use them, or not, as you deem them necessary. Just because most people choose not to use MSPL in their code doesn't mean they think it's bad. I'm not sure I entirely agree with the argument that "nobody uses it, so they think it's bad". In C I don't use unions much at all. I don't use them simply because I don't see a need for them in the majority of my code, but by your argument, I think that unions denote poor style. > P.S. "Code Complete" and "The Pragmatic Programmer" are *required* > reading for anyone who fancies themselves to be a computer programmer. Much like Knuth's "The Art of Computer Programming" is *required* reading? I've met programmers who haden't read that series at all (and were so good that they really didn't need to). Yet I wouldn't refuse to call them computer programmers simply because they didn't read a book or three. To say that any book is required reading is silly. Will the book help? Quite likely. Is it an absolute necessity for success in the field? No. Your little P.S. adds to the stench of "I'm better than you" that your entire article (except for the quote) reeks of.
From: Alex McDonald on 7 Apr 2006 16:13 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). > > 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. > [snipped] Perhaps factoring (aka refactoring) is just as important; that is, as few lines of code (or statements, or whatevers) per function/subroutine. Long functions/subroutines are difficult to understand, and are perhaps best replaced by removing what could be common sub-functions to somewhere else, and calling them. Of course, the ultimate in code factoring is not to write the code at all, unless you really need to. You can put factored code in a shared source library and INCLUDE it; or an object code library if your assembler/linker supports it, or at least a run-time load library. Good factoring makes your code cleaner, faster, and easier to read. This is the antithesis of cut&paste coding. Resist it! http://www.cyberconf.org/~cynbe/muq/muf3_5.html#SEC5 http://en.wikipedia.org/wiki/Refactoring -- Regards Alex McDonald
From: JGCASEY on 7 Apr 2006 17:07 randyhyde(a)earthlink.net wrote: > 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 mantra for readable code: > "You write readable code for OTHER people, not for > yourself." Point taken. ... > > 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). The reason I put in line breaks is because when they are too long the google reply post thingy does it anyway with strange results. xxxxxxxxxxxxxxxxxxxxxxxxxxxx yyyyyyyyyyyyyyyyyyyyyyyyyyyy becomes, xxxxxxxxxxxxxxxxxxx xxxxxxx yyyyyyyyyyyyyyyyyyy yyyyyyy ... > > 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). Your credentials are fully known to me Randy. I often wonder why you bother with ala? see thread: When caveman Uhg invented fire From: Rod Pemberton - Thurs, Apr 6 Oh, of course, I forgot, self promotion of HLA :) -- JC
From: randyhyde@earthlink.net on 7 Apr 2006 17:10
James Daughtry wrote: > I can't speak for anyone else, so this is pretending that your post is > directed at me and not "people who don't get it" in general. You are certainly in this class, but don't think you're the only one I'm addressing. Look back in the archives. This topic seems to come up every year or so. > > I really do appreciate your enthusiasm, so please don't take this the > wrong way. But, even if you didn't intend for it to be, your post is > dripping with condescension. You assume that anyone who advocates > anything but a single statement per line hasn't read Code Complete or > The Pragmatic Programmer and you tailor the rest of your post to the > assumption that we're all ignorant students of yours that can't > comprehend the wonderful things you're trying to explain. Every year this subject comes up. Forgive me for being tired of it. But by 2006, people *ought* to know that this is just bad practice. Alas, it seems that the assembly hackers (and that's a group I'm *not* putting you in, btw), seem to be decades behind the rest of the world when it comes to using best practices that have been honed via lots of experimentation and measurement over the past 40 years. > > Well, Randy, I'm not one of your students. I've read Code Complete (and > The Pragmatic Programmer) several times, cover to cover, and taken the > time to understand the reasoning behind each option. Fair enough. > On top of that, > I've done a *lot* of research into readability and good programming > style that's taken me well beyond the beaten path. It's not that I > don't "get it". You're trying to explain something to me that I already > know (as well as you, possibly even better), in a way that makes you > come off as an arrogant prick. I am arrogant. Nothing new there. When it comes to good programming style I certainly admit that there are many things I do differently than what is common practice (e.g., I tend to use a lot of macros, which is considered bad style). But I don't try and preach such transgressions as good programming style. That is the difference between me and those (such as yourself, this time) that try to promote bad practices as though they were good. > Here's why: > > > 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). > > This is the impression I got from your opening paragraph: > > Every now and then, some dumbass shows up spouting nonsense about style > that I know is wrong. Well, here's what I really said: Relatively often around here someone, typically from the RosAsm camp (that would include Rene, Wannabee, and yourself at this point) shows up making claims about programming style that run contrary to everything Software Engineering has taught us over the past 40 years. > Usually it's Betov and his minions, I.e., "The RosAsm Camp" or "The RosAsmites". > but > occasionally someone who fancies himself a computer programmer tries to > make life hard for us "real" computer programmers by "thinking outside > the box" and coming up with something the smart people have proven to > be bad. That box was thought outside of a long time ago. Keep in mind, people actually *used* to do what you're proposing. It didn't work out. Perhaps you are so arrogant as to think you can convince the world to adopt your "out of the box" style when it's been rejected before? You never can tell, extreme programming has convinced a lot of people that they don't need to comment their code. :-) > I'm going to write a long article explaining exactly why I'm > right and everyone else is wrong by quoting from a book and making > comments on it. The book is well respected, so in turn, my approving > comments of the book should also be respected. Versus you writing a long article claiming that I'm wrong because I quoted from a well-respected and highly-popular book on the subject? Are you saying that my comments should *not* be respected because they happen to agree with the author of the world's most popular book on this subject? Finally, I'm not claiming that everyone else is wrong. Quite the contrary; only a *few* people seem to be claiming that multiple statements per line is a good thing. If *everyone* were claiming that this is a good thing, then both McConnell's and my opinions on the subject would be off the mark. After all, it is the expectations of the majority that dictate what is good programming style. Again, if you want to argue against McConnell's work, be my guest. You do so at your own peril. Understand one thing, though. The popularity of his book is amazing. He's taking a subject that people have deep religious feelings about and turned it into a book that nearly everyone purchases and reads. While almost everyone disagrees with something or another he says in the book, the fact that most people overwhelmingly agree with him says something. > > Even without my blatantly sarcastic translation, your opening paragraph > sounds a lot like you're stroking your ego by putting down people who > don't completely agree with you. Now, as expected since you're using a > very good book as reference material, you make some good points: > > > 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). > > I think you're exaggerating. It seems like you're under the assumption > that MSPL (unnecessary acronym?) are used as a complete replacement for > other methods of logical grouping and that statements are "crammed" > together all willy nilly. That's not the case when MSPL is used > correctly, and exaggerating the truth into your own version so that > your arguments make more sense is deceptive. I'm still waiting for a definition of what "correct use of MSPL" means. I've asked for that from you in the other thread, you've not provided this. Now I'm sure you can make stuff up. But as I said there, I want some evidence that validates your claims. True, I can wimp out and rely on the research that has already been done that claims MSPL is a bad thing, but it's also the case that I've see a lot of BASIC code written in the MSPL style. Granted, most of that was overkill and didn't follow any kind of logical organization, but the fright remains. And let me ask this *very* important point: suppose you do find a few examples where MSPL produces "better" results. Is it *so* much better that it's worth the inconsistencies of using MSPL in some case and not in others (because of other problems, such as line length)? > > As for a single scheme, how do you explain that any good code will use > both blank lines *and* indention for logical grouping? They're using whitespace in either case. Dig out your copy of Code Complete and re-read chapter 18 ("Layout and Style"). McConnell makes some very good cases for the use of indentation and blank lines. And one interesting comment he makes is that no more than 16% of the lines should be blank. (Actually, to be 100% accurate, he says that research indicates that code containing more than 16% blank lines is harder to *debug*, not read.) This is one area where I stubbornly disagree with him. I'm more than happy to inject 20-25% blank lines into my code if it makes it more readable. Then again, because indentation doesn't work as well in assembly as it does in HLLs, blank lines are probably more important. But based on what I've read in McConnell, I'm not going to get into a knock-down, drag-out argument about whether my insistence on extra blank lines is a good thing or not. Research indicates that such code is hard to debug, and unless I'm willing to do the research myself to prove or disprove this (which I'm no), I'm willing to accept those findings (of course, being harder to debug does *not* imply that it's harder to read; so additional research would be necessary to prove that point). > That's not as > much the case with traditional assembly formatting, but I find that > style difficult to read after it gets to a certain length. I'm familiar > with the syntax, so ignorance of the language clearly isn't my problem > in this case. ;-) Unless you want to claim that I have to have a > certain amount of experience reading assembly programs before I'm > allowed to have an opinion on readability. Of course you need a certain amount of experience reading assembly before you can have an *educated* opinion on the subject. I am not suggesting, however, that you do not possess that experience. Nor do I believe I've ever suggested that you don't have that experience. Indeed, the current debate (MSPL) really has little to do with assembly language. All the arguments for and against MSPL are largely language-independent. So even if you don't know a single thing about assembly, experience with HLLs such as C/C++ would certainly qualify you to have an opinion on the subject. > > > 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. > > Well, in theory this sounds good, but let's consider the '<test> > <jump>' MSPL idea. Sure, you could factor that into a subroutine...hmm, > or not, because that's the epitome of silliness. A macro could work, > but you would need to pass the label as an argument. You would also > need to pass the test as an argument as well, or write multiple macros > that do different tests. Wait, why even bother? Oh, right, so you don't > repeat yourself. O_o bge value1, value2, label Doesn't seem that silly to me. Of course, I argue that if you're going for readability, then you try to avoid (programmer-visible) labels as much as possible because they don't show the logical structure of the program well. This is what the structured programming revolution was all about, after all. That's why HLL-like control structures (macros) are a good thing in assembly. Something like if( value1 < value2 ) then .... endif is quite a bit more readable to most people than something like cmp value1, value2 | jge >L0 .... L0: Particularly when there are multiple instances of L0 floating around in the source file. > > The fact of the matter is that where MSPL works, refactoring doesn't. > It's either impractical or illogical. Often, where MSPL works, blank > lines don't help readability quite as much, in my opinion (even though > it's close). Ah, but here's an important point. In those instances where you can make a *valid* claim that MSPL works better than blank lines, blank lines still come close. So is it really worth the inconsitencies and other problems that come from using MSPL. There's one other issue to consider, to. Being careful about using MSPL is like being careful about using GOTOs. There are definitely some instances where using a GOTO makes the code more readable. But is it worth the problems when *not* using a GOTO is only a *little* more messy (for example, you save one level of nesting in some control structure sequence). And like GOTOs, once you turn on the faucet to allow a few MSPLs in appropriate spots, it gets real easy to start using in other places to. And as the code gets maintained by others (particularly, others who are not as careful about using MSPL wisely), the code tends to degenerate. I've seen some C programs, for example that started out with a single GOTO in them. Programmers working on the code later on saw the GOTO and figured it was okay to use them, as they were already in use in the program. So they added a few more. Well-placed ones, I might point out. Before too long, this process leads to spaghetti coding. Bottom line is this: *one* occurrence of MSPL in a typical program is not going to affect the readability of that program in any measurable fashion. The same is basically true of almost any other bad programming style. One occurrence of a bad name isn't going to affect the program's readability much. One occurrence of an incorrect control structure won't affect the readability much. One case of poor indentation (horizontal or vertical) won't affect things much. A program doesn't become unreadable because of one mistake. It's more like the death of 1,000 paper cuts. And that's why you want to avoid bad practices like MSPL. You most certainly can justify a few bad practices now and then and claim they're all for the better. But the next compromise becomes easier. And the next even easier. It's a slipperly slope you don't want to wind up on. > Blank lines and MSPL are simply two tools that you can > use. You use them, or not, as you deem them necessary. Again, you're missing the point of writing readable code. It isn't what *you* deem necessary (or whatever), but what other people expect. Now if you're writing code for other people who *expect* MSPL, then by all means use it. But people with such expectations are few and far inbetween. > > Just because most people choose not to use MSPL in their code doesn't > mean they think it's bad. Most people don't think about it at all. Until they see it, that is. And then they typically say "what is this?" It's not what they expect, and that's a *bad* thing. > I'm not sure I entirely agree with the > argument that "nobody uses it, so they think it's bad". In C I don't > use unions much at all. I don't use them simply because I don't see a > need for them in the majority of my code, but by your argument, I think > that unions denote poor style. If MSPL were dictated by the language, or was necessary for certain algorithms, then you'd have a point. But it's strictly a formatting issue that is independent of algorithm implementation (at least, in free-format languages like C). The same cannot be said of unions. When they are necessary, attempting to simulate them by some other means (e.g., constant type-casting or setting up pointer aliases) is clearly worse. There is no question that if you abuse unions, and use them for things where they're not appropriate, this is a bad thing. However, there are times when it is appropriate to use a union; those times may be rare (e.g., I probably create new union types about once a month, on the average), but when those times happen, unions are the best way to do the job. You've failed to provide an example were MSPL is *obviously* the right thing to do and splitting the statements across separate lines is obviously the *wrong* thing to do. > > > P.S. "Code Complete" and "The Pragmatic Programmer" are *required* > > reading for anyone who fancies themselves to be a computer programmer. > > Much like Knuth's "The Art of Computer Programming" is *required* > reading? I've met programmers who haden't read that series at all (and > were so good that they really didn't need to). Yet I wouldn't refuse to > call them computer programmers simply because they didn't read a book > or three. 15 years ago I would have claimed that Knuth was required reading by anyone. But since then some excellent data structures and algorithm books have appeared, so Knuth no longer stands out as well as it once did (not to mention the fact that the field has progressed a bit since then and Knuth, though we are seeing revisions, has fallen a bit behind). Certainly, I would argue that anyone who has not carefully studied data structures and algorithms cannot call themselves a "real" programmer. There are other canonical software engineering books that every programmer should read. Software Tools, Elements of Programming Style, The Mythical Man-Month are examples that immediately come to mind. I would put these books, and several others for that matter, on the required reading list. Programmers who don't read, aren't. > > To say that any book is required reading is silly. That's absolutely correct. Reading a "book" does you no good if you don't apply the information therein. And it's the information that's important, not what book it appeared in. So I humbly admit I made a mistake. Someone can read the same material found in Code Complete or The Pragmatic Programmer by reading dozens of other books, papers, and journal articles and learn the same information (as well, undoubtedly, lots of other information). > Will the book help? > Quite likely. Is it an absolute necessity for success in the field? No. I guess it all depends on what you consider success. If you're constantly writing code that other people find unreadable, because you've refused to learn the basic of good programming style, I wouldn't consider that to be the apogee of professional development. > Your little P.S. adds to the stench of "I'm better than you" that your > entire article (except for the quote) reeks of. Go back and read your post. And as the saying goes, "physician, heal thyself". Claiming I'm an "arrogant prick" really reeks of "I'm better than you are..." Cheers, Randy Hyde |