Hmmm ... Well it's almost always a personal preference isn't it. In general, I think that naming conventions should be such that not only I understand what's going on in my source code, but also so does whoever else comes across my code. Also, I tend to be a minimalist in code documentation; unless I am doing something very tricky, my code should be smart enough to explain itself to me even if I see it 3 years from when I wrote it in a drunken stupor. So consistency across your projects, for internal sanity is important too.
For instance, when I use C on *nix systems, I invariably use 0 as success and negative numbers for flagging failures; with the exception on I/O functions where return is size_t; then positive number is amount of I/O; 0 is a halt on I/0 and (size_t)-1 is a fault with errno set to a system error; this is consistent with C library behavior on the systems so I know that everyone will understand what is going on.
When I used to write programs under Win32 using C the convention of Win32 was a bit different and I followed that convention. There, the names use camelCase in C (which is annoying to me but I follow it) and use Hungarian notation (which is even MORE annoying) but I stick to using that.
However if I were to write equivalent code in C++ I would switch the way I report errors. Throwing exceptions or using boolean return values for simpler methods.
If I am in kernel programming mode, then I use the conventions used by kernel developers;
I figure that I do NOT want to spend time explaining my code to others (which includes me 3 - 5 years from now because I'd have changed) so I use the dialect that they'd understand on their own rather than me having to explain MY logic to them (they really aren't that smart, and I am getting stupider by the year).
I think whatever you use, keep it consistent along some logic path that can survive across languages, across systems and your growth between now and 10 years from now.