Idiotic programming style edicts
in [General Programming]
|
From: Richard Bos on 27 Apr 2010 10:07 Patrick Scheible <kkt(a)zipcon.net> wrote: > cbcurl <cbcurl(a)gmail.com> writes: > > On Apr 25, 3:43=A0am, Patrick Scheible <k...(a)zipcon.net> wrote: > > > spinoza1111 <spinoza1...(a)yahoo.com> writes: > > > > That's what the code looks to a professional programmer. > > > > > > No, that's what the code looks like to a programmer who's a bit green > > > or rusty on C and doesn't pick up on its idioms. > > > > > > "Professional programmer" is a meaningless phrase as there is no > > > professional certification comparable to doctors or lawyers. > > > > "Professional programmer" just means you get paid to program and > > largely make a living doing so. Just like "professional musician", > > "professional golfer", etc. The more you get paid, the more > > "professional" you are. ;-) > > Was Bernie Madoff a professional investment adviser? He got paid for > it pretty well... Yup. A very corrupt, untrustworthy professional investment adviser, but someone who made his profession out of giving investment advise. Similarly, a professional C programmer is, by the main definition, someone whose job involves programming in C. One may find overtones of "with care" or "skillfully" in the term, but those are, at best, secondary definitions. Richard
From: Seebs on 27 Apr 2010 11:43 On 2010-04-27, blmblm myrealbox.com <blmblm(a)myrealbox.com> wrote: > In article <slrnhtbf6j.2e5.usenet-nospam(a)guild.seebs.net>, > Seebs <usenet-nospam(a)seebs.net> wrote: >> 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? It is, but there's a hook: extern int pseudo_debug(int, char *, ...) __attribute__ ((format (printf, 2, 3))); (all one line in the original, wrapped for Usenet). -s (In the actual code, the function is named something else, For Historical Reasons.) -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Scott Lurndal on 27 Apr 2010 11:47 blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> writes: >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? declare as follows: extern size_t snprintf(char *, size_t, const char *, ...) __attribute__(( format(printf,3,4), nonnull(1,3) )); scott
From: Anne & Lynn Wheeler on 27 Apr 2010 11:47 raltbos(a)xs4all.nl (Richard Bos) writes: > Yup. A very corrupt, untrustworthy professional investment adviser, but > someone who made his profession out of giving investment advise. one might claim that it just represented the culture the person testifying in the congressional hearings into madoff last year (who had tried unsuccessfully for a decade to get the SEC to do something about Madoff) commented that new regulations may be needed but by far the most important was improved transparency and visability. re: http://www.garlic.com/~lynn/2010h.html#54 Trust Facade In the early 90s, we were brought into a small client/server startup that wanted to do payment transactions on their server ... they had also invented something called "SSL" that they wanted to use. The result is now frequently called "electronic commerce". There were various assumptions about deployment and use of SSL for it to be secure. Almost immediately some number of those assumptions were violated. As a result, I coined the term "merchant comfort certificates" (i.e. SSL providing a sense of comfort rather than real security). http://www.garlic.com/~lynn/subpubkey.html#sslcert In the mid-90s, somewhat as a result of the work on "electronic commerce", we were invited to partake in the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments .... which resulted in the x9.59 financial retail payment standard. http://www.garlic.com/~lynn/x959.html#x959 NSCC participated in X9A10, but were (also) interested in secure ACH payments. We weren't members of NACHA, so NSCC responded to a NACHA secure payments RFI (on our behalf) http://www.garlic.com/~lynn/nacharfi.htm which was followed by a NACHA secure payments pilot. http://web.archive.org/web/20070706004855/http://internetcouncil.nacha.org/News/news.html In the late 90s, we were also invited into NSCC (since merged with DTC to become DTCC) to look at redoing trading transactions (to add more security/integrity). That activity was suspended fairly early because a side-effect of the security would be increased visibility and transparency ... which apparently is antithetical to the trader culture. Note that in the early part of this century, various secure payment products ran into something similar (but different). The SSL "electronic commerce" got high uptake from financial institutions, in part because they were classified MOTO transactions (highest interchange fee). Prospect of secure payments products, initially had high acceptance among internet merchants because they were expecting two-factor authentication debit/POS interchange fees (or better). There was then major "cognitive dissonance" among internet merchants when the financial industry told merchants that "secure payments" products would basically be a surcharge ontop of MOTO interchange fees (i.e. higher than MOTO fees, rather than much less). -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: Patrick Scheible on 27 Apr 2010 11:54
spinoza1111 <spinoza1111(a)yahoo.com> writes: > On Apr 27, 12:10=A0am, 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. =A0But in many cases, self-taught programmers can run rin= > gs > > > 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. =A0For law, they need to > > pass the bar exam as well. =A0For 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. =A0Of 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. Sure. But there's a tremendous amount of art to programming that is not provable, just good practice. -- Patrick |