Quote of the week
Posted Mar 1, 2007 5:31 UTC (Thu)
by pr1268 (guest, #24648)
[Link] (24 responses)
Having read Linus' reply, I kind of get why Linux has been so successful: It's the quality assurance model of hundreds of skilled developers with good taste all looking out for each other. A network of trust has been built amongst some of the more experienced kernel hackers (People such as Andrew, Greg, Alan, Theodore, Adrian, Al, and others come to mind) who are given a bigger share of responsibility for ensuring the quality of the kernel code remains high. Plus, it seems anytime Linus' comments get posted on LWN, it's often a rant or tirade about sloppy kernel programming (if not about some marketing or legal blunder that negatively impacts Linux [i.e. DRM, etc.]). This is not meant as criticism. In fact, I bookmark a lot of these posts because Linus generally has nothing but adroit, intelligent advice on programming, operating system theory, and computers in general. I gather that Linux also owes much of its success to the idea that many FLOSS community members respect Linus for his expert knowledge. I certainly do. Enough with the Linus-gushing. I know the difference between skilled and unskilled kernel programming, but can someone give me an example of bad taste in programming? ;-)
Posted Mar 1, 2007 6:15 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
Windows ME
I know certainly that that POS left me with a bad taste all around.
Posted Mar 2, 2007 5:26 UTC (Fri)
by pr1268 (guest, #24648)
[Link]
Off-topic: I think the Windows ME period of my home computing history lasted all of 3 hours. Spring 2000, if I remember correctly, and I installed it fresh on my homebuilt computer. When I tried right-clicking a file inside of Windows Explorer → copy → right-click in blank area of Explorer → paste, the Explorer shell screamed bloody murder telling me "Cannot paste file, it already exists!" (All I was trying to do was duplicate a file in the same folder. Every other OS I've ever used [including other variants of Windows] has allowed me to at least give a different name for the new file.) I couldn't wipe the hard drive fast enough to rid my PC of that vile, contemptible trash.
Posted Mar 1, 2007 10:57 UTC (Thu)
by NRArnot (subscriber, #3033)
[Link] (3 responses)
Just about everything that inflicts a GUI interface without a scriptable command-line equivalent. Especially if it is obvious that the same thing is likely to need to be done many times over to a set of entities, and double-especially if the GUI actions spread themselves over more than one screen (so you can't even just type in the next entity name and OK again).
Really good taste would be a GUI interface that generated command lines where you could see them (and scroll, edit and re-execute them). Then the GUI would become a learning tool rather than a barrier to learning.
Posted Mar 3, 2007 17:40 UTC (Sat)
by dwkunkel (guest, #5999)
[Link]
Posted Mar 8, 2007 10:36 UTC (Thu)
by bk (guest, #25617)
[Link] (1 responses)
Posted Mar 8, 2007 23:49 UTC (Thu)
by i3839 (guest, #31386)
[Link]
Good taste is to write your programs in a modular fashion so that slapping different kinds of interfaces on top of it is peanuts, no matter if yourself are only interested in one.
This makes it also easier to write KDE/Gnome/Qt/GTK/FLTK/ncurses versions of GUIs, as not everyone wants to install all existing kitchen sinks just to run a single application. And you know what, it makes it much easier to port such programs to different environments much easier. 3D OpenGL GUI, or a low resources embedded device: Same code, only different GUI, your program shouldn't care.
Other good taste is to dynamically load needed libraries when you need them, instead of creating a dependency hell of mostly unused libs, which cause programs to fail starting up when they miss. Compile options are NOT an option: Distro's will just enable them all, just in case.
Posted Mar 1, 2007 11:37 UTC (Thu)
by Randakar (guest, #27808)
[Link]
Well, it's easy to gush; As far as kernel development goes his track record of being right on the money is pretty good IMHO*.
Of course one may not always agree with how he stands on the political divide with regards to licensing, but at least the man's viewpoint there is well-articulated and understandable. (wrong, but understandable ;-) )
*) and I've been watching for years
Posted Mar 1, 2007 19:36 UTC (Thu)
by nix (subscriber, #2304)
[Link] (6 responses)
On the micro-level, it's Bad Taste to write code which `happens to work'
struct foo *get_foo(int a, long b, const char *c);
and they wanted to return `a foo', `no foo to find' and `error while
And *that* was bad taste. Sure the pointer was never dereferenced if it
(of course I called it. Of course I didn't expect this return value. But
Posted Mar 2, 2007 0:41 UTC (Fri)
by cpeterso (guest, #305)
[Link] (3 responses)
http://msdn2.microsoft.com/en-us/library/aa363858.aspx
Posted Mar 2, 2007 1:00 UTC (Fri)
by k8to (guest, #15413)
[Link] (2 responses)
Posted Mar 3, 2007 2:05 UTC (Sat)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Mar 4, 2007 9:04 UTC (Sun)
by k8to (guest, #15413)
[Link]
I've unfortunately programmed the win32 api before, although in its "sanitized" form, called Mono.
Posted Mar 2, 2007 2:04 UTC (Fri)
by proski (subscriber, #104)
[Link] (1 responses)
Posted Mar 3, 2007 2:08 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Mar 3, 2007 4:37 UTC (Sat)
by ldo (guest, #40946)
[Link] (5 responses)
Null-terminated strings.
Posted Mar 5, 2007 13:35 UTC (Mon)
by nix (subscriber, #2304)
[Link] (4 responses)
Posted Mar 5, 2007 21:14 UTC (Mon)
by k8to (guest, #15413)
[Link] (3 responses)
Certainly using them where they don't belong is awful, but I don't see a problem with them fundamentally.
Posted Mar 6, 2007 0:50 UTC (Tue)
by ldo (guest, #40946)
[Link]
Back in my Mac programming days (pre-OS-X), the APIs were full of "Pascal"-format strings, which started with a length byte. A maximum length of 255 may not sound like much, but I estimated that over 90% of the string objects in my programs fitted quite comfortably into this limit.
One thing, I was always careful to pass maximum buffer lengths. To reduce the chance of mistakes, I used macros like this:
which I would use like this:
That way, if the destination buffer was too small for the string, the worst that would happen was that it was truncated--you would never get overwriting of random memory.
Posted Mar 6, 2007 6:59 UTC (Tue)
by njs (subscriber, #40338)
[Link] (1 responses)
Posted Mar 6, 2007 22:52 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Plus, the length byte was never long enough, and the overhead of keeping
String ADTs make more sense :) internally they can do whatever they like,
I did this and more with an adaptive string ADT I wrote a few years ago
There would doubtless be more tricks I could have used, but that was all I
One of these days I should rewrite it (I'd call it `clean it up' but it's
(Judy trees, which I didn't discover till much later, of course knock the
Posted Mar 5, 2007 23:29 UTC (Mon)
by ldo (guest, #40946)
[Link] (1 responses)
errno(3).
Posted Mar 6, 2007 23:07 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Mar 6, 2007 15:49 UTC (Tue)
by bronson (subscriber, #4806)
[Link] (1 responses)
I'd love to know who was responsible for this one. He should spend the rest of his days trying to explain it to people just learning C. Students seem to think it's some strange example of good design ("well, if strncpy does it, then it must be OK") and emulate it in their own programs. *shudder*
Posted Mar 8, 2007 6:53 UTC (Thu)
by ncm (guest, #165)
[Link]
The real mistake was adopting it into the ANSI C standard library as if it were a regular string function. Of course it's equally a mistake to use it. Nowadays, snprintf() might be a better choice, but a function that calls abort() if its argument is longer than the buffer would be better still. The BSD strlcpy() is another mistake, a fact fortunately recognized by POSIX.
Of course the right thing is to eliminate null-terminated string operations, but that's harder to retrofit.
Posted Mar 1, 2007 6:49 UTC (Thu)
by pr1268 (guest, #24648)
[Link]
The whole "skilled programmers with good taste" blurb was part of Linus' entire message; only an excerpt appears on this page. My original post is identical on both pages.
Some idle comments about Linus' e-mail response and Linux
""I know the difference between skilled and unskilled kernel programming, but can someone give me an example of bad taste in programming?""Some idle comments about Linus' e-mail response and Linux
Off-topic: Windows ME
Bad taste in programming?Some idle comments about Linus' e-mail response and Linux
Oracle's SQL Developer does this. Almost anything that you can do with the GUI has a tab labeled SQL that shows the SQL code that will be executed. This has also been an integral part of Oracle's Enterprise Manager for many years.Some idle comments about Linus' e-mail response and Linux
While I agree in general, the GUI-frontend-to-a-command-line-engine design is backwards and horrid. The communication is nearly always in one direction with no clear way to communicate failures or unforseen events to the user. In fact most of the time the app can't even indicate 'busy, please wait...', it just hangs frozen for an indeterminate period of time.Some idle comments about Linus' e-mail response and Linux
He doesn't ask for a GUI front-end slapped on top of a command line interface, he asks for programs that have both both kinds fully functional. And preferably the GUI version prints out the command with options what would do the same action as the GUI action just performed.Some idle comments about Linus' e-mail response and Linux
Some idle comments about Linus' e-mail response and Linux
All the examples so far have been macro-level.Some idle comments about Linus' e-mail response and Linux
without concern that it's grossly, obviously disgusting. e.g. one I saw
many years ago (and fixed at once) had a function looking ocnceptually
something like (identifiers anonymized to protect the guilty)
looking for a foo'. So they returned a foo, NULL, and, um, (struct foo *)
1.
was 1, so it wasn't technically a standards violation. But the hidden
unexpectedness of that return value, and the absence of any hint except in
its various callers that this might happen made it Bad Taste. (To add
insult to injury get_foo() also assumed a different meaning for a
null-string-valued `c' parameter and for a NULL `c'...)
when the program crashed on an error path, I didn't consider it *my*
fault. It was the fault of the author of get_foo(). Some adjustment of
55-odd callers later, and it was no longer doing such a vile thing.)
Win32's CreateFile() API scores many Bad Taste points:Some idle comments about Linus' e-mail response and Linux
The name, for starters.Some idle comments about Linus' e-mail response and Linux
The billion insane flags and magic secret interactions are worse. It makes Some idle comments about Linus' e-mail response and Linux
open()+fcntl() look sane and pleasant.
Oh absolutely. I just find it impressive that they couldn't even figure out that "files" are not just windows api constructs, but really exist on the disk, and so the name is just wrong. It's like opening and closing quotes to the explitive which is the implementation.Some idle comments about Linus' e-mail response and Linux
And here we see Linus himself suggesting almost the same thing. No, it's not that bad, since it's a valid pointer, but it's close enough :)
Some idle comments about Linus' e-mail response and Linux
The &bad_ctype is non-tasteless, I'd say. It's *transparent* and you can Some idle comments about Linus' e-mail response and Linux
easily tell what it's doing when you read the code. And it doesn't dump
core if you dereference it :)
bad taste
...but can someone give me an example of bad taste in programming?
Also, length-prepended strings. :)bad taste
Is there a real problem with length-indicated strings, or just using them in environments that are built around something else?bad taste
bad taste
#define Descr(v) (void *)&v, sizeof v
CopyString(Src, Descr(Dst));
Dunno what nix was thinking either way, but I'd draw a real sharp distinction between "length prepended" and "length indicated". string buffer plus length sitting next to it (or wrapped up in a structure) = The Right Thing, string buffer with initial byte overloaded to indicate length = eewwwwwwww.bad taste
Quite.bad taste
the length up to date dominated surprisingly often, even dead-reckoning
them. At least with null-terminated strings you don't need to work out the
length unless you need it.
possibly a varying representation depending on the length.
for an application my then employer wanted. If you kept asking for the
length of a string it started tracking the length itself; if you kept
inserting and deleting from it, and it was long enough, it switched the
representation to a buffer-gap; if you kept on asking for subsets of the
string and it was long enough to blow the dcache (I randomly picked 64Kb),
it turned itself into a position-keyed binary tree, and if the string was
long enough and rarely-read enough it started zipping the longer and
more-rarely-referenced hunks up with zlib.
needed to get performance up for that application. It wasn't dealing with
strings longer than 200Mb, after all. ;)
too dirty for that, it needs a rewrite, not least because I want to hold
the copyright this time) and release it, only there's probably no point as
someone else has doubtless written something much better.
socks off this, but their API uses such awful names for basically all its
functions that I've not yet been able to bring myself to use them. I
wonder if they'd accept a patch adding names that it's actually possible
to remember? The Great Lowercase Letter and Vowel Shortage ended *years*
ago...)
bad taste
...but can someone give me an example of bad taste in programming?
Also h_errno and all that it implies; hell, the entire bad taste
grossly-non-Unixlike BSD networking stack.
strncpy(3) leaving truncated strings unterminated.Some idle comments about Linus' e-mail response and Linux
In its origin strncpy() had one purpose: filling in directory entries in Version 7 Unix file-system code. It was always called with a length argument of 14, which was the size of the filename field in the struct, and the limit on filename length. Directory entries were zero-filled, not null-terminated.
strncpy
Clarification