Idiotic programming style edicts
in [General Programming]
|
From: spinoza1111 on 26 Apr 2010 23:11 On Apr 27, 12:10 am, Patrick Scheible <k...(a)zipcon.net> wrote: > "Jennifer Usher" <jennisu...(a)gmail.com> writes: > > "Patrick Scheible" <k...(a)zipcon.net> wrote in message > >news:w9zoch8rn7p.fsf(a)zipcon.net... > > > > "Professional programmer" is a meaningless phrase as there is no > > > professional certification comparable to doctors or lawyers. > > > This is true. But in many cases, self-taught programmers can run rings > > around those with degrees, especially those with two year degrees from > > community colleges. > > True, but in part that happens because a computer science degree just > means the student has finished the coursework. For law, they need to > pass the bar exam as well. For medicine, they need to complete their > residency as well. > > Also at least in some schools the computer science coursework is > mostly theory -- automata theory, computational complexity, etc. - and > deliberately does not teach programming technique. Of course, it > would be difficult to teach techniques for writing and managing large > programs in a one-semester course. "Theory" means it's TRUE and we can KNOW it. > > -- Patrick
From: Nick Keighley on 27 Apr 2010 05:39 On 26 Apr, 18:11, "Charlie Gibbs" <cgi...(a)kltpzyxm.invalid> wrote: > In article > <6d90c101-4e77-4b99-996a-9cafec56c...(a)y17g2000yqd.googlegroups.com>, > > cbc...(a)gmail.com (cbcurl) writes: > > I think it is widely agreed that C's default fallthrough behavior > > is not desirable, but I fail to see the harm in making use of this > > feature as long as you use an explicit comment to indicate that it > > is intentional and not an accident. > > In the example we're arguing about, the fallthrough cases are empty. > I see nothing wrong this this; it's basically syntactic sugar for an > IF statement with two conditions joined by ||, except that it allows > other cases to be dealt with in the same construct. > > The real danger is forgetting the break statement at the end of a > non-empty case; that's when the really strange things start happening. > If you really want such behaviour, then an obvious comment is in order - > although I admit that it gives me a queasy feeling to even think about > doing it. I've played around with this layout to make it obvious that the breaks are there switch (c) { case 'a': process_a(); break; case 'b': process_b(); break; default: error(); }
From: blmblm on 27 Apr 2010 07:16 In article <slrnhtbf6j.2e5.usenet-nospam(a)guild.seebs.net>, Seebs <usenet-nospam(a)seebs.net> wrote: > On 2010-04-26, blmblm myrealbox.com <blmblm(a)myrealbox.com> wrote: > >> > > switch (msg->op) { > >> > > case OP_FCHOWN: /* FALLTHROUGH */ > >> > > case OP_FCHMOD: /* FALLTHROUGH */ > >> > > case OP_FSTAT: > >> > > prefer_ino = 1; > >> > > pseudo_debug(2, "%s %llu [%s]: ", pseudo_op_name(msg->op), > >> > > (unsigned long long) msg->ino, > >> > > msg->pathlen ? msg->path : "no path"); > >> > > break; > >> > > default: > >> > > pseudo_debug(2, "%s %s [%llu]: ", pseudo_op_name(msg->op), > >> > > msg->pathlen ? msg->path : "no path", > >> > > (unsigned long long) msg->ino); > >> > > break; > >> > > } > > He cheats, of course, by stripping the comment line immediately above the > switch(): > > /* debugging message. Primary key first. */ > > >> The two calls to pseudo_debug2 do the same thing, and one of them > >> appears to get the parameters out of order! > > Actually, no. As part of its general pattern of paranoia and resilience, > the pseudo client attempts to provide the server with two separate kinds > of identification of each file: > * its inode number (a raw entry on the disk allowing you to > identify a distinct file) > * its path name > > For most operations, the path name is the "dominant" key, and the inode > number is there only for sanity checking. However, for three operations > (fchown, fchmod, fstat), the original program will have been working on > the raw descriptor for an already-opened file; this file could be renamed > after being opened, or we may never have found the name of the file, so > the inode becomes the primary key and the path the secondary key. Thus, > I swap the order of the two arguments to display the more significant > one first. Ah -- I wondered why you presented the same information in two different ways. The explanation -- explains it. > >> if (msg->op == OP_FCHOWN || msg_op == OP_FCHMOD || msg_op == FSTAT). > >> prefer_ino = 1; > >> pseudo_debug(2, "%s %llu [%s]: ", pseudo_op_name(msg->op), > >> (unsigned long long) msg->ino, > >> msg->pathlen ? msg->path : "no path"); // > >> If this, indeed, is the right order > > This is a noticably less maintainable piece of code (consider what > happens if the list expands beyond three items). C's switch is used > in these cases for a good reason. > > >> Even if it is possible to call pseudo_debug in one case with an > >> unsigned 64 bit second parameter, and a string in the other, if for > >> some reason the code in pseudo_debug supports this polymorphism, it is > >> simply unacceptable. > > > To me it seems likeliest that pseudo_debug is a variadic(?) function, > > taking arguments similar to those passed to fprintf. That second > > parameter looks very much like a printf-style format string, and the > > remaining parameters seem to me to match up fine with its conversion > > specifiers. > > Exactly. This is a standard idiom. And thanks to a mildly non-standard > extension, gcc is providing type checking for these arguments, comparing > them to the format string appropriately. Hm, interesting .... How does gcc know to do this checking? I've observed that it *does* produce such warnings for the *scanf and *printf functions, and very useful those warnings are, too, but if I'd had to guess I'd have said it had been hard-wired to do this checking for a specific set of functions. Maybe not? -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 27 Apr 2010 07:18 In article <519257a9-785e-43d8-871d-9801d2200dfb(a)x24g2000prc.googlegroups.com>, spinoza1111 <spinoza1111(a)yahoo.com> wrote: > On Apr 26, 9:46 pm, blm...(a)myrealbox.com <blm...(a)myrealbox.com> wrote: > > In article <09b14a6e-23bb-4fc0-8d66-1e7164746...(a)h16g2000prf.googlegroups.com>, > > > > spinoza1111 <spinoza1...(a)yahoo.com> wrote: > > > On Apr 24, 8:26 pm, Nick Keighley <nick_keighley_nos...(a)hotmail.com> > > > wrote: > > > > On 24 Apr, 07:39,spinoza1111<spinoza1...(a)yahoo.com> wrote: > > > > > > > On Mar 21, 2:17 am, Seebs <usenet-nos...(a)seebs.net> wrote: > > > > [ snip ] > > > > > > > >http://github.com/wrpseudo/pseudo > > > > [ snip ] > > > > > > > > > > > > > > > switch (msg->op) { > > > > > case OP_FCHOWN: /* FALLTHROUGH */ > > > > > case OP_FCHMOD: /* FALLTHROUGH */ > > > > > case OP_FSTAT: > > > > > prefer_ino = 1; > > > > > pseudo_debug(2, "%s %llu [%s]: ", pseudo_op_name(msg->op), > > > > > (unsigned long long) msg->ino, > > > > > msg->pathlen ? msg->path : "no path"); > > > > > break; > > > > > default: > > > > > pseudo_debug(2, "%s %s [%llu]: ", pseudo_op_name(msg->op), > > > > > msg->pathlen ? msg->path : "no path", > > > > > (unsigned long long) msg->ino); > > > > > break; > > > > > } > > > > > > > Here's the same somewhat cleaned up practice, but here you should have > > > > > defined the assignment of prefer_ino, the pseudo_debug and the break > > > > > as a macro. Better yet you should have used an OR statement. > > > > > > could you illustrate the use of an OR statement with an example? > > > > > Sure: and this rewrite indicates something even probably more horrible > > > and less professional about this code > > > > > It is that despite the fact that you or Peter claim to want to use > > > switch with fall thru "to avoid repeated code" (which ignores a basic > > > form of abstraction), your switch statement has repeated code! > > > > > The two calls to pseudo_debug2 do the same thing, and one of them > > > appears to get the parameters out of order! After two months work, > > > this is unacceptable and makes a sick joke out of Peter's libel of > > > Schildt. > > > > > if (msg->op == OP_FCHOWN || msg_op == OP_FCHMOD || msg_op == FSTAT). > > > prefer_ino = 1; > > > pseudo_debug(2, "%s %llu [%s]: ", pseudo_op_name(msg->op), > > > (unsigned long long) msg->ino, > > > msg->pathlen ? msg->path : "no path"); // > > > If this, indeed, is the right order > > > > > Even if it is possible to call pseudo_debug in one case with an > > > unsigned 64 bit second parameter, and a string in the other, if for > > > some reason the code in pseudo_debug supports this polymorphism, it is > > > simply unacceptable. > > > > To me it seems likeliest that pseudo_debug is a variadic(?) function, > > taking arguments similar to those passed to fprintf. That second > > parameter looks very much like a printf-style format string, and the > > remaining parameters seem to me to match up fine with its conversion > > specifiers. > > That's what I was thinking when I speculated that Dweebach is using > polymorphism, our object oriented term for what in C is barbarously > called "variadic". I'm using "variadic function" in the sense described in the Wikipedia article http://en.wikipedia.org/wiki/Variadic_function to denote a function that accepts a varying *number* of arguments. I'm not sure that's quite the same thing as polymorphism. [ snip ] > I don't have the time, or patience, to hunt down Peter's incompetent > code: but it appears he is misusing C's bad implementation of > polymorphism out of vanity, even as he codes what should be OR > statements or operator tables as case statements with fallthrough in > order to show off. This is because it's bad practice to use > polymorphism when there are a small finite number of cases as there > appears to be here. Instead, three + small n >=0 functions should be > created: > > 1. A function that implements the logic with all possible alternative > arguments and a flag to select the right argument > > 2. n>=2 wrappers each with hardened alternative types > > Variadics should only be used when the number of alternative types is > unknown or unbounded. Otherwise strong types should be preferred. It seems to me that the pseudo_debug function is intended to be in some sense analogous to the *printf functions -- something that allows for the printing, or logging, or something, of messages that consist of some fixed text and some information to be filled in at runtime by applying conversion specifiers to values of expressions. Allowing the number and type of expressions to vary from (textual) call to call strikes me as useful and reasonable, particularly in the context of a language in which this is the (a?) normal and idiomatic way of producing formatted output. I may be missing something, but your proposed alternatives strike me as significantly less flexible and useful. <shrug> [ snip ] > There seems to be a consensus > (from which I demur) that programmers need rich switch/case statements > that allow sets of known cases to be grouped. I demur even if > structured syntax is in use because of my OO experience. When the > normal American programmer makes a decision that something's a set, > it's often the wrong decision. For example, he later realizes after > eating too much at lunch that members of the set can also belong to > other sets, and codes a case statement where a value appears at two > places in the switch, and is never recognized at the second place. Do you mean something like the following, where in foo() there are two occurrences of "case 0"?: #include <stdio.h> void foo(int n) { switch (n) { case 0: printf("first case 0\n"); break; case 1: printf("case 1\n"); break; case 0: printf("second case 0\n"); break; default: printf("default case\n"); } } int main(void) { foo(0); foo(1); return 0; } If so, be advised, for what it's worth, that gcc won't compile this code, giving an error message "error: duplicate case value" about the line with the second "case 0". No idea whether this is standard behavior, but it seems to me that maybe it should be -- I mean, isn't the point of switch/case to allow creating a jump table, and wouldn't duplicate values make that impossible to do? -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
From: Michael Wojcik on 27 Apr 2010 08:34
Patrick Scheible wrote: > "Jennifer Usher" <jennisuzan(a)gmail.com> writes: > >> "Patrick Scheible" <kkt(a)zipcon.net> wrote in message >> news:w9zoch8rn7p.fsf(a)zipcon.net... >> >>> "Professional programmer" is a meaningless phrase as there is no >>> professional certification comparable to doctors or lawyers. >> This is true. But in many cases, self-taught programmers can run rings >> around those with degrees, especially those with two year degrees from >> community colleges. And in many cases they can't. Without actual data, this is a vapid observation. > Also at least in some schools the computer science coursework is > mostly theory -- automata theory, computational complexity, etc. - and > deliberately does not teach programming technique. This is a weakness in the accreditation requirements for CS undergrad programs in the US. (I haven't studied the situation is like in other countries.) There is perennial debate about the problem; Bjarne Stroustrop (who I believe is currently the chair of the CS department at Texas A&M) wrote a piece about it in CACM not that long ago. > Of course, it > would be difficult to teach techniques for writing and managing large > programs in a one-semester course. No it's not. It's difficult to get more than a couple months' practice with them, but it's quite easy to teach and practice those techniques. You make the students work in decent-sized groups, and work on a large project that's already in progress. (Roll the project over from semester to semester.) Make the students use appropriate techniques like change management, problem tracking, and the development methodology of your choice - waterfall, an agile approach such as XP or Scrum, or whatever. The important point is that they use *some* methodology other than the "stay up all night pounding at the keyboard on their own private solution to some trivial problem" one beloved of intro CS courses. When I was an undergrad at Northeastern, we did this in a couple of classes, including compiler design, where the entire class worked on an in-progress Modula II compiler. We started by imposing a proper development environment with revision control and project and issue tracking. More recently, I helped a colleague run a mixed undergrad/grad course - actually in tech comm and rhetoric - where the students built a complex web app using Ruby on Rails, with all the code maintained in Subversion. A few weeks into the semester, they were writing code (Ruby, HTML, CSS) and testing it locally, then committing it to the central repository so it could be picked up in the next deployment to the public server. The class ran two sprints over the course of the semester, with self-organized feature teams. And most of them had no programming or software development experience. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University |