complement to $

[bearophile]

Nick Sabalausky:

>Once upon a time, there was a book called "Writing Solid Code".<

I have not read this book. Thank you for the suggestion, I will read it. There are tons of books about programming and computer science, but the good books are very uncommon, I can probably write a list of less than a dozen titles. So given few years it's easy to read them all.


>It seemed that anyone who was an established, respectable programmer swore by it and proclaimed it should be required reading by all programmers.<

"Writing Solid Code" is a book about programming, but its examples are in C and it's focused on C programming. Today some people write code all day and they don't even know how to write ten lines of C code. Time goes on, and what once was regarded as indispensable, today is less important (in my university the C language is taught only at about the third year, often in just one course and the teacher is not good at all, the code written on the blackboard can be sometimes used by me as examples of how not write C code). This happens in all fields of human knowledge. In practice given enough time, almost no books will be indispensable. Books that are interesting for centuries are uncommon, and they are usually about the human nature (like novels) that changes very little as years pass :-)


>and reading "The One-Function Memory Manager"<

C99 has changed things a bit:

>In both C89 and C99, realloc with length 0 is a special case. The C89 standard explicitly states that the pointer given is freed, and that the return is either a null pointer or a pointer to the newly allocated space. The C99 standard says that realloc deallocates its pointer argument (regardless of the size value) and allocates a new one of the specified size.<

I agree that C realloc is a function that tries to do too many things. C libs are not perfect.


>"Wishy-Washy Inputs",<

Python supports named functions arguments (as C#4, and I hope to see them in D3), this can reduce the bug count because you can state what an argument is at the calling point too.

The code of CopySubStr is bad:
- Abbreviated names for functions (and often variables too) are bad.
- Unless very useful, it's better to avoid pointers and to use normal array syntax [].
- There is no need to put () around the return value in C.


>that many of the cautions in it sound like no-brainers today, like not using return values to indicate error codes.<

Generally in Python when some function argument is not acceptable, an exception is raised. Exceptions are used in D for similar purposes. But in D you also have contracts that I am starting to use more and more.


>So much of the book has made such an impact on me as a programmer, that from the very first time I ever heard of a language (probably Python) using "someArray[-5]" to denote an index from the end, I swear, the very first thought that popped into my head was "Candy-Machine Interface". I instantly disliked it, and still consider it a misguided design.<

A negative value to index items from the end of an array is a bad idea in C (and D), it slows down the code and it's unsafe.

But you must understand that what's unsafe in C is not equally unsafe in Python, and the other way around too is true. A well enough designed computer language is not a collection of features, it's a coherent thing. So its features are adapted to each other. So even if a[5] in Python looks the same syntax as a[5] in C, in practice they are very different things. Python arrays are not pointers, and out-of-bound exceptions are always present. And often in Python you don't actually use a[i], you use something like:

for x in a:
  do_something(x)

As you see there are no indexes visible here (as in D foreach).

What I am trying to say you is that while I agree that negative indexes can be tricky and they are probably too much unsafe in C programs (given how all other things work in C programs), they are not too much unsafe in Python programs (given how all other things work in Python programs). In Python you have to be a little careful when you use them, but they usually don't cause disasters in my code.


>But even for those, it goes into much more detail on the "why" than what you usually hear.)<

It looks like a good book.

Bye,
bearophile