Coding Standards

Quote:

---

Originally Posted by OReubens

0 is a numeric value of zero. NULL is a pointer value. You should use them appropriately. Using 0 when you mean a pointer value is just bad form.

Additionally writing 0 where you mean NULL may work on compilers now, but it may very well cause problems in the future when suddenly standards decide that char *p = 0; is no longer valid.
It can also be confusing to someone else. Did you mean to make a char pointer that is pointing to memory location 0? Or did you try to set the char pointed to by the pointer p to 0 ?

---

Actually, 0 is also a null pointer constant, as is NULL, which is a macro that could well be defined as 0. As such, unless the compiler implements some special checks that are not required by the standard, the use of NULL over 0 provides a false sense of security, although it can provide some clarity, if you are willing to trust it.

The real solution is nullptr, which should be part of the next version of C++. Consequently, the argument that there is a possibility that "suddenly standards decide that char *p = 0; is no longer valid" is likely to apply for NULL as well. The argument concerning confusion is weak: if the reader could be confused by that syntax, then changing 0 to NULL does not necessarily remove the confusion, e.g., are you trying to set the char pointed to by the pointer p to NULL?

Quote:

---

Originally Posted by OReubens

The only reason I can see to write 0 instead of NULL is to save typing 3 characters.. But I prefer code clarity over typing a 3 characters a lot more.

---

Stroustrup's reason is to avoid the use of a macro, where feasible.

I like to use tabs and not spaces because it makes it so much easier to remove one tab versus 4 spaces.

Also I want to mention that Code::Blocks does support reformatting of your project source code to a lot of different coding styles. Even making tabs into spaces. One could easily code in a different style and simply run AStyle plugin to convert that style into the standard style. This can help save time and frustration. AStyle is pretty good, there are a few things that can be improved.

Also AStyle can be downloaded and used as a command line, but of course this is harder, but doesn't require Code::Blocks

http://astyle.sourceforge.net/

Quote:

---

Originally Posted by Lindley

What if you want to change the type of a variable from signed to unsigned? Should you have to go replace every instance of it?

---

To be honest, I could probably count on 1 hand the number of times I needed to change a variable's type from signed to unsigned (or vice versa). And if I did need to, yes, I'd change the variables' name as well. It's not like Search & replace is particularly difficult to do.

Quote:

---

Originally Posted by Lindley

Occasionally such a change may introduce a logic error (such as a loop counting down to 0 may not work with an unsigned int counter), but usually not.

---

Whether you use camelCase, Hungarian notation or something else, changing a variable's type between signed and unsigned may introduce logic errors. I don't see how that is in any way relevant to the camelCase vs Hungarian notation discussion.

Well this is pretty much how it is. We all have our preferences and I just hate tabs... ;)

I like to format my code for (what I consider) readability and that includes adding spaces here and there. If tabs are used I have to syncronize the settings for every single editor/viewer I come across to be able to use it for code. :(

Quote:

---

Originally Posted by laserlight

Stroustrup's reason is to avoid the use of a macro, where feasible.

---

I know Stroustrup's stance on the matter, it's been quoted on the dev team many times before.

The thing is. If you're a solo developer, then youc an pretty much do what you like since you're the only one needing to understand your code.

If you're in a habit of working in a team of many developers with new people joining the team on a regular basis, then code readability is much much more of a concern over a lot of other issues people tend to throw around.

* NULL is better at conveying a meaning (a pointer pointing to nowhere), than 0 (a pointer ? a value ?). So it's prefered. So what if it uses a macro ? I see no bad side to it. We already have preprocessing to do a lot of other stuff anyway, so you're not going to save noticably in the area of compiletime, or compiler memory use. And even if, code clarity still is an order of magnitude more important than getting a 0.1s faster compile or having the compiler use 100 bytes less memory.

* If a bunch of macro's can make it easier to understand/write a bit of code, then that's preferred, even if the macro's can be complex on their own. you'll be benefitting from the ease of the macro's a lot more than having to write/maintain the actual macro's themselves.
MFC's messagemaps? Heck yes ! I'd hate to be forced to write all of the underlying bits each and every time.

We have several of those same type of macro's generating tables/functions in our own sources.


You don't get more productivity in a team by saving on macro's, or by saving on typing short identifier names. Stuff like intellisense helps in actually typing the long names. Self explanatory identifiers make life easier if you're maintaining code someone else has written.

Quote:

---

Originally Posted by OReubens

* NULL is better at conveying a meaning (a pointer pointing to nowhere), than 0 (a pointer ? a value ?). So it's prefered. So what if it uses a macro ? I see no bad side to it. We already have preprocessing to do a lot of other stuff anyway, so you're not going to save noticably in the area of compiletime, or compiler memory use. And even if, code clarity still is an order of magnitude more important than getting a 0.1s faster compile or having the compiler use 100 bytes less memory.

---

The bad side is that the macro conveys a meaning that is not necessarily the truth, i.e., it may be the case that NULL was used by mistake, and actually an integer, not a pointer, really was intended. Contrast this with nullptr, which conveys a meaning that must be, otherwise a compile error will result.

So, it is not an issue of compile time. It is an issue of whether one can truly trust the clarity that purportedly results.

Quote:

---

Originally Posted by OReubens

* If a bunch of macro's can make it easier to understand/write a bit of code, then that's preferred, even if the macro's can be complex on their own. you'll be benefitting from the ease of the macro's a lot more than having to write/maintain the actual macro's themselves.

---

I agree, if there are no feasible and pragmatic alternatives.