What's the fastest way to get from a function call back to its definition during the editing process? If you're using something like Notepad or an IDE, the answer is usually to search for the file containing the function, open it, and search your way down to the definition. Unfortunately, if you want to
We all know (or at least we should know) that we can use #define to create macros that replace names with values during the preprocessor phase of compilation. Sometimes, it's very important for us to have the ability to change large amounts of code very quickly, because we have a new size limit for
On Friday, I spent a number of hours trying to run down an error in a fairly substantial piece of code. All I really knew was that I kept getting an error that said something like:
*** glibc detected *** ./my_program: malloc(): memory corruption: 0x0000000002296980 ***
When I pushed this piece of code through gdb, I
If you've spent any appreciable time in the programming world, you've probably reorganized your code any number of times. When I'm writing code, I usually slap things out as I think of them, resulting in code that (while easy enough to read) defies the principle of unity. You'll see me write things like this:
The hardest interview I ever had: someone told me to go up to a whiteboard and solve a programming problem, in code, optimally, on the first try.
It's a basic fact of our field that we iterate toward the final product. Not unlike a sculptor bringing the David out of a piece of marble, we
A wise quote: When it goes without saying, someone should probably say it.
This is one of the better known patterns out there, but it still bears repeating.
The boundaries for integers
When you're working with a range of integers (for example, human age range could be between 0 and 135), we have two obvious boundary points
Has this ever happened to you: a program crashes, and all you get is a black screen or a set of meaningless numbers?
I know it happens to me.
While it's usually less of a problem in C, in my Java days I saw any number of functions with names like solve or act. These functions were usually overloaded, so that solve meant one thing for integers and a wholly different thing for strings.
In 99.9% of cases, programmers spend most of their planning and initial coding creating the program that they want. They then spend twice as much time adding error-handling code to the original program, because they forgot that things can (and often do) go wrong.
This is happy path programming, or success oriented code.
I don't know how many hundreds of functions I've dealt with with either a void or boolean return type. While a boolean return type at least tells us whether the function ever completed properly, a void return carries absolutely no meaning. Where's the debugging or error-handling value in that?
Constructor functions take a number of