Idiotic programming style edicts
in [General Programming]
|
From: Nick Keighley on 28 Apr 2010 04:30 On 27 Apr, 06:39, spinoza1111 <spinoza1...(a)yahoo.com> wrote: > On Apr 26, 9:46 pm, blm...(a)myrealbox.com <blm...(a)myrealbox.com> wrote: <snip> > > To me it seems likeliest that pseudo_debug is a variadic(?) function, > > taking arguments similar to those passed to fprintf. almost beyond doubt I'd say. It's such a well known c-idiom I'm surprised spinoza needs it spelling out (but to be fair he doesn't claim to be a C programmer). <snip> > 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". don't use words you don't understand. Look up "polymorphism". Wikipedia probably has a reasonable page on it. Also look up "variadic" > ["Variadic" is barbaric, since it is not a word, never understand people who say this. Someone told me "homophobic" wasn't a word because it meant "fear of sameness". ITYM "it's an ugly neologism". variadic has been around since at least 1989 and probably much longer. > and when incompetent > programmers and incompetent language designers coin neologisms by > making a mess of a real word, as does "variadic" wrt to "variant", > their incompetence is subconsciously mirrored in their destruction of > language. "Variadic" does not appear in the complete OED but > "polymorphism" does.] and they aren't the same > [...] it appears [seebach] is misusing C's bad implementation of > polymorphism [...], even as he codes what should be OR > statements or operator tables as case statements with fallthrough [...]. > This is because it's bad practice {OPINION} 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: printf-style logging functions are quite elegant and useful. C++'s iostreams look ok until you try and do any formatting (like hex or limit places in floating formats). Then they start to look quite messy. > 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. strong types should be preferred but logging is one place variadic functions are useful. <snip> > However, here, he's giving reasons for his horrible code while > cowering behind your apron strings. 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. your grasp of OO lacks opposable thumbs the use of a case statement is often a sign that you *haven't* used polymorphism properly. case (end_point.type) mobile: send_to_mobile (end_point) despatcher: send_to_despatcher (end_point) pstn: send_to_pstn (end_point) can be replaced (after defining appropriate clases) with end_point.send() I'm not too up to date on OO and but I always quite liked Booch's "Object Oriented Analysis and Design" as a fairly solid introduction to OO. But for getting to the nub of the matter Martin's "Agile Software Devlopment" is unbeatable. [why did no one tell me about the Open Closed Principle before!]. > Rich switch statements, as opposed to the Bohm Jacopini structures, > can cause code with hidden bugs to be accepted UNLESS the compiler > analyzes the flow AND constants are used and not variables as case > labels. C doesn't allow variables as case labels. <snip> > Seebach didn't like my OR of the three cases because it doesn't scale. I'm with him on that. It's harder to read as well. > That is correct. However, the competent programmer prefers, at the > point where n doesn't scale, creating a fixed table which he can > initialize and lookup, using linear search for small n, linear search > of a presorted table for medium n, or hashing for larger n. A large > switch statement (especially with multiple case labels) WANTS to be a > data structure. well some people do in some circumstances. But not everyone. I don't accept that hiding this in a datatype necessarily makes for more readable code. Beneath the smooth Nile of your data abstraction lies the crocodile of abstraction inversion. <snip> > Competent code (such as my code) giggle. > I grant, looks completely bizarre and > incompetent to the regs here, and perhaps others as well. <snip> -- Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.
From: Dave on 28 Apr 2010 04:48 "Charlie Gibbs" <cgibbs(a)kltpzyxm.invalid> wrote in message news:1302.804T1043T12023944(a)kltpzyxm.invalid... > In article <m3ljc8nbi0.fsf(a)garlic.com>, lynn(a)garlic.com > (Anne & Lynn Wheeler) writes: > >> 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 > > Sad but true. Many of the people who condemn Madoff would jump at > the opportunity to do just what he did. > >> 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. > > Yeah, and here in British Columbia we have two levels of government - > federal and provincial - who both campaigned on a platform of "open, > accountable government", only to become so secretive once in power > that even their respective Auditors-General can't figure out what's > going on (although they have a pretty good idea). Ah "AUDITORS", the professionals who ring me up and say they have lost a laptop. On enquiring they didn't have an exit procedure and they hadn't recorded the fate of several leavers machines. Could I tell them if they were still being used, and if so where.... > > -- > /~\ cgibbs(a)kltpzyxm.invalid (Charlie Gibbs) > \ / I'm really at ac.dekanfrus if you read it the right way. > X Top-posted messages will probably be ignored. See RFC1855. > / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign! Dave Wade MBCS, CITP >
From: Michael Wojcik on 28 Apr 2010 12:36 Nick Keighley wrote: > On 27 Apr, 06:39, spinoza1111 <spinoza1...(a)yahoo.com> wrote: >> ["Variadic" is barbaric, since it is not a word, > > never understand people who say this. They're idiots who can't be bothered to learn how English works. There - mystery solved. The criteria for word-status in English are very liberal: an English word is simply a series of letters used as a word in an English phrase. There is no generally-recognized authority for the English language, so there can't be any other constraints. And no, neither the OED nor any other dictionary constitutes such an authority. Of course there are various subsets of English words, of the form "English words recognized with the same general meaning among the members of speech community X", and dictionaries can be useful in defining those subsets. But so can other records of English usage. Clearly we have ample records of the use of "variadic", so we can establish that it is not only an English word, but one with a generally-recognized meaning for at least one speech community (loosely, those with a decent understanding of the C programming language). -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Michael Wojcik on 28 Apr 2010 12:49 Ahem A Rivet's Shot wrote: > On Tue, 27 Apr 2010 08:34:01 -0400 > Michael Wojcik <mwojcik(a)newsguy.com> wrote: > >> 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.) > > I like this - they also get to experience the joys of working with > other people's code that they haven't got the time to completely rewrite so > they have to learn to read and understand it. Absolutely. This is hugely important for CS students who are going to become programmers in any significant way (in industry, or working on open-source projects, etc), because so much of the job is reading other people's code. I gave a presentation at the Association of Teachers of Technical Writing Annual Conference last year where I argued that CS and similar programs need to include coursework in writing human-readable code (and suggested that tech-writing teachers might be the ones to teach such a course). >> 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. > > For a final feature they could be working on something that they > actually have to use. Yes. If the project's sufficiently advanced, they might be required to use the system they're working on, either for the same class or for another; if it's still in the early stages, they could at least exercise the code by writing unit tests and so on. Building a compiler or a virtual machine work well for that, because that's something CS students can reasonable use for unrelated projects. For the web-app class we did here at MSU, which I described in the previous email, many of the students were also contributing content to the site (it's one of those social-media user-generated-content sites that lets people post articles and photos and whatnot) as it was being developed. So they were eating their own dogfood, and there was a nice tight develop-deploy-use-revise cycle. There was also another undergrad class contributing content in the same semester, and they were breaking things and feeding back problem reports and requests for features (in the form of user stories). In the following semester, we had an undergrad/grad digital rhetorics class do user research and design critique for improvements for the next iteration of the site, some of which were rolled out at the end of that semester. A colleague and I are writing a chapter for an upcoming book, "Designing Web-Based Applications for 21st Century Writing Classrooms", on using agile development in writing classes where students are creating web apps. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Patricia Shanahan on 28 Apr 2010 20:58
Michael Wojcik wrote: > Patrick Scheible wrote: .... >> 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. .... I would like to see something like this, but done as a two semester course where the students do not have to do anything specific during the second semester, but get a grade based on the results for a successor group working on their code. The course would automatically put a premium on readable code, including *useful* documentation and comments. Students who write obscure code during the first semester will spend a lot of time during the second semester explaining things to their successor group. Patricia |