I used to be a student of the ``Defensive Programming'' school of programming. I'm mainly a C programmer, but I occasionally dabble in languages such as LISP. Anyways, whenever I would program in C, I would program very defensively, and check that all the arguments passed to every function were not NULL (assuming they were pointers. This turned my code into mostly a bunch of if statements.
After a while, I figured out that this was pointless, and most of the functions I write today, I don't bother checking if the arguments are NULL or not, because only a smart fucker such as myself is going to be using them. I instinctively know when everything is NULL or not. Of course, I do still check the arguments sometimes, but definitely not in every function. It just turns into a mess.
What do you guys do? Am I a retard, or are you similar?
Overcautious function argument validation shows you've spent more time writing user-facing things than you have libraries for programmers to use.
Just don't bother. Idiots who pass bogus arguments to functions shouldn't be surprised when the whole thing segfaults (and when it does, it's because of something they did wrong, not you, and they have the power to fix it themselves (unlike end users)), and people who don't will thank you for the speed gains and the increased legibility of your code.
Name:
Anonymous2008-09-13 19:01
>>1
I'm a duck programmer. I never check for anything, just catch exceptions if shit fucks up (it’s easier to ask forgiveness than permission). In particular, I never ever check for the types of anything. My functions rely heavily on dynamic typing. They work as long as they work. If I write a function double to duplicate something by adding it to itself, I'll never ever check what the fuck I'm duplicating; I just call + on the object. If the object supports +, and + doesn't fuck up with itself, then it's done.
This approach maximizes reusability and minimizes duplication of effort. My functions work with anything they could possibly work with, including objects from completely different programs; even those that didn't exist at the time I wrote my function, without any sort of massive inheritance tree or interfaces or any of that Java-ish bullshit for faggots.
Of course, I use THE FORCIBLY INDENTED LANGUAGE PYTHON.
Name:
Anonymous2008-09-13 19:27
One word, assert.h, thread over.
Name:
Anonymous2008-09-13 19:39
If you're writing a library you should check the arguments of the functions that can be called by an user of the library, because the user can pass anything to your functions. If you give an error instead of segfaulting it's easier to locate the error and the user knows immediately that it's his fault. For internal functions you don't have to check the arguments, because then only you can fuck it up.
Name:
Anonymous2008-09-13 19:41
I almost only validate variables where wrong values might lead to logical errors or if i'm sure, invalid values may be passed from time to time. In other cases I just wait for a crash to fix instead of writing 100 ifs and a few lines of code that actually do something usefull.
For internal functions you don't have to check the arguments, because then only you can fuck it up.
And we know that can never happen.
Name:
Anonymous2008-09-13 20:48
Ha! Look at you plebian programmers dabbling with dangerous side effects. It's easy for me as a functional Scheme programmer to deal only with the expected cases and disregard everything else.
Name:
Anonymous2008-09-13 21:01
When you must fail, fail noisily and as soon as possible.
I prefer a segfault than a silent fail, because the latter leads to lots of tracing and "now where did that pointer get set to null? It's going to be pretty hard to tell if the fuckton of functions called since have just been returning and letting things continue..."
I've also seen stuff like this:
a=1;
... /* a bunch of code which doesn't do anything at all with a */
if(a!=1) {
/* some sort of error-recovery shit */
}
...
I don't think you should be checking the hardware to see if it's doing things right (unless it's a diagnostic program of some sort), because if the hardware is dying then all bets are off for the software.
Name:
Anonymous2008-09-13 21:29
>>10
>When you must fail, fail noisily and as soon as possible.
But how do you do this if you are writing a library? GLib is gross, it just logs errors and warning to stdout.
in Croatia we have a saying: a program with no error checking is just a program with error checking but with error checking removed.
the moral of the story
┌┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┐
┤This is an x86 ├
┤microchip!! ├
┤Copy it to help├
┤it proliferate.├
└┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┘
Name:
Anonymous2008-09-15 15:22
>>19
┌┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┐
┤This is a patented IBM/390 mainframe ├
┤ 31-bit millichip! ├
┤ Don't copy that floppy. ├
┤ Disobedience will be punished ├
└┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┘
Name:
Anonymous2008-09-15 23:20
Look, I fucking hate C for this reason. What if like, I actually WANT to point to 0x00000000? What the hell is really wrong with that? A null pointer is a pointer too. Fuck off, C-tards.
>>21 What if like, I actually WANT to point to 0x00000000? char getb(char *ptr){
char b;
asm volatile (
"movb (%1), %0"
: "=r" (b)
: "r" (ptr)
);
return b;
}
void setb(char *ptr, char b){
asm volatile (
"movb %1, (%0)"
: : "g" (ptr), "g" (b)
: "memory"
);
}
Name:
Anonymous2008-09-16 5:47
>>21
A null pointer is defined as a pointer that never points to a valid memory location. It doesn't necessarily have to be 0x00000000. If 0x00000000 is a valid memory address on your architecture the null pointer can't be 0x00000000.
Name:
Anonymous2008-09-16 6:31
>>25
What about a system on which all integers point to valid memory locations?
(⌒＼. ∧_∧ In an imaginary world,
＼ ヽヽ（ ・ω・） are we even responsible for our actions?
(mJ ⌒＼
ﾉ ________/ ／
（ （｡・-・）＜ What are you doing?
／＼丿 l|＼⌒⌒⌒ ＼
(___へ＿ノ. ＼|⌒⌒⌒⌒|
>>58
I chuckled while I snorted while I loled while I stared humorlessly.
Name:
Anonymous2008-09-17 6:08
Back in Croatia, my mother country, we have a saying about programs. The saying goes that programs without error checking are equivalent to programs with error checking, but with error checking disabled. The moral of the saying is that the user has no way of knowing if a program has or has not error checking. Much like how Schroedinger's cat may or may not be alive inside that box, you have no way of knowing.