Multiple Statements per Line
in [ASM]
|
From: JGCASEY on 10 Apr 2006 20:12 Evenbit wrote: > JGCASEY wrote: > > Evenbit wrote: > > [ ... ] > > I think programming also has a creative element. It requires an > > architect. Of course the creative person doesn't have to be the > > tradesman, but if the tradesman is too expensive, he might just > > be a hobby builder, then the architect has to do it himself. > > I agree. Viewing programming as just a trade is too simplistic and too > simple-minded and leaves out a great deal of the overall picture. > Reading comments at Digg, Slashdot, here, and elsewhere, I see that a > lot of people don't quite "get it" and seem to ignore the creative, > marketing, and other aspects involved in the programming arena. For > instance, a lot of "typical users" are barely capable of using the > mouse -- let alone would they know enough about computers to care > whether the programmer has read a certain book or not. What are the > chances that a client/customer is going to make a purchasing decision > based on the readability of your code, whether you extensively used > black boxes or not, did you use an unconventional syntax?, did you use > a "text convertor" or a "PE editor toy"?, is your code the most > efficient?, how much education/experience do you have?, etc.... All > the client/customer cares about is that the product works -- performs > as advertised! Ultimately it is the product not the academic bickering that counts. Being a professor of a language doesn't mean you would have a clue how to write a Harry Potter novel even if you knew more about grammar, spelling and so on than the Harry Potter author. > > The debates between Rene and Randy present perspectives from extremely > opposing poles of an extremely wide spectrum on many topics. Most of > these present many questions that don't have easy answers. > > Nathan.
From: hutch-- on 10 Apr 2006 22:36 smile, > Dont you mean : "I dont need to have any expertise in hat eating, as I > have found a way to pretend I know anything about it, even though I > actually have never had any competance in hat eating. My comptance field > is rather in POWER hat eating" No as a matter of fact, you were the one caught with your pants down trying to feed bullsh*t to the members of the group and you also made the mistake of promising to eat you hat. Now its put up or shut up time, chew that hat until you have digested it and when you pass it out the other end, not only will you have a further drop in intellect as it passes out with the hat but you will clear your mind as well. Regards, hutch at movsad dot com
From: Dragontamer on 10 Apr 2006 23:00 JGCASEY wrote: > Evenbit wrote: > > JGCASEY wrote: > > > Evenbit wrote: > > > [ ... ] > > > I think programming also has a creative element. It requires an > > > architect. Of course the creative person doesn't have to be the > > > tradesman, but if the tradesman is too expensive, he might just > > > be a hobby builder, then the architect has to do it himself. > > > > I agree. Viewing programming as just a trade is too simplistic and too > > simple-minded and leaves out a great deal of the overall picture. > > Reading comments at Digg, Slashdot, here, and elsewhere, I see that a > > lot of people don't quite "get it" and seem to ignore the creative, > > marketing, and other aspects involved in the programming arena. For > > instance, a lot of "typical users" are barely capable of using the > > mouse -- let alone would they know enough about computers to care > > whether the programmer has read a certain book or not. What are the > > chances that a client/customer is going to make a purchasing decision > > based on the readability of your code, whether you extensively used > > black boxes or not, did you use an unconventional syntax?, did you use > > a "text convertor" or a "PE editor toy"?, is your code the most > > efficient?, how much education/experience do you have?, etc.... All > > the client/customer cares about is that the product works -- performs > > as advertised! > > Ultimately it is the product not the academic bickering that counts. > > Being a professor of a language doesn't mean you would have > a clue how to write a Harry Potter novel even if you knew more > about grammar, spelling and so on than the Harry Potter author. Of course; it is quite different for say, English vs Writing than it is for Computer Science vs Programming. Programming has many "solved" problems where a textbook answer just fits so cleanly where the uneducated may spend a couple of days trying to hack up an incomplete solution. Basically; methinks Computer Science education helps Programming more than English education helps writing books. (Obviously though; someone who has read Shakespeare; Greek, Egyptian Norse Mythology, Chinese history and so forth, they probably have a lot more stories to "borrow" to enhance their book. So education still helps writers, just not as cleanly as programming me thinks) --Dragontamer
From: JGCASEY on 10 Apr 2006 23:28 Dragontamer wrote: > JGCASEY wrote: [ ... ] > > Ultimately it is the product not the academic bickering that counts. > > > > Being a professor of a language doesn't mean you would have > > a clue how to write a Harry Potter novel even if you knew more > > about grammar, spelling and so on than the Harry Potter author. > > Of course; it is quite different for say, English vs Writing than it is > for Computer Science vs Programming. I was thinking more (computer science and programming) vs (creative application) > Programming has many "solved" problems where a textbook answer > just fits so cleanly where the uneducated may spend a couple of > days trying to hack up an incomplete solution. > > Basically; methinks Computer Science education helps Programming > more than English education helps writing books. > > (Obviously though; someone who has read Shakespeare; Greek, Egyptian > Norse Mythology, Chinese history and so forth, they probably have a lot > more stories to "borrow" to enhance their book. So education still > helps writers, just not as cleanly as programming me thinks) Education always helps. But there comes a time to implement that education otherwise it amounts to nothing more than intellectual ..... -- JC
From: randyhyde@earthlink.net on 12 Apr 2006 15:32
James Daughtry wrote: > > I find it interesting that you, and Randy it seems, assume the author > *won't* be the reader. No. Just that readability metrics aren't as important if no one else reads your code. > If you write code with something you find > awkward just to placate other people, what happens if *you* turn out to > be the next person to maintain the code a year later? "Placating other people" generally means sticking to well-thought-out standards (not always, accepted C programming style is a counter-example in many instances) whereas writing code for yourself allows you to utilitize a scheme you've *taught* yourself to think is readable, but is actually less readable than a different style. Code that other people find readable immediately after you've written it will probably still be readable to you a year later. > On the other > hand, if you write code in a consistent and logical style, anyone can > figure it out with minimum effort, including you. Self-consistent is certainly better than completely inconsistent, but consistent with the way most people do the task is usually better. > > As an example, I wrote a component and promptly forgot about it. Then, > about three years later, I was faced with the same component. Much to > my shock, it used a completely different style than I enjoyed at the > time because I had changed my preferences, as most people do. But I had > no trouble getting used to the awkward style because it was consistent. That's not particularly amazing. People often do *much* better at reading their own code (good or bad) than they do reading other people's code. Again, the real question is "how many other people would have found that code easy to read?" Once again, if the code is for your eyes only, it doesn't really matter if the rest of the world thinks it's readable or not. You can use any style you like in that case. > > The only times I've had issues maintaining other people's code are when > the code didn't use a consistent style, or the style was exceptionally > illogical and I couldn't figure out why something was done the way it > was. Touche. > > Anyway, code is only written once. Hopefully not. Hopefully the programmer refactors the code on a regular basis to make it better. > A good maintainer will maintain the > style because not doing so breaks consistency. Or will change the style during refactoring, if the previous style was particularly bad. > Even if you write for > the next person, the person after that may find your style horrible. This is why it's important to adopt well-accepted programming styles. > Formatting is very much a holy war. Everyone has a different opinion, > and they're all happy to force their opinion on others. Re-read Code Complete. McConnell has managed to do the unthinkable -- to get most people to agree on what's important with respect to style. Style is not about where braces go, but how you use formatting to logically represent the program's meaning. > > On the topic of multiple statements per line, I'll readily admit that > people think it's bad style. I'll also admit that people think other > things I do are bad style, even if the majority thinks those things are > good style. If I try to write code with a "perfect" style that everyone > agrees with, I'll never get anything done. So I find a happy medium in > consistency and logic so that people can at least figure out my style > with relative ease. :-) Well, as long as you're conciously admitting that other people think it's bad style and you're going to do it anyway, who can argue with that? Cheers, Randy Hyde |