complement to $

Nick Sabalausky a at a.a
Sat May 15 11:16:41 PDT 2010


"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:hsm7l9$27nt$1 at digitalmars.com...
> Nick Sabalausky:
>
>>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 :-)
>

Yea. The book is heavily C, of course, because C was heavily used at the 
time. But, I think another reason for all the focus on C is that the typical 
(at least at the time) C-style and the standard C lib are filled with great 
examples of "what not to do". ;)

>
>>"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.
>

Yea, non-named-arguments-only has been feeling more and more antiquated to 
me lately.

> The code of CopySubStr is bad:
> - Abbreviated names for functions (and often variables too) are bad.

There are two major schools of thought on that. On one side are those who 
say full names are more clear and less prone to misinterpretation. The other 
side feels that using a few obvious and consistent abbreviations makes code 
much easier to read at a glance and doesn't cause misinterpretation unless 
misused. Personally, I lean more towards the latter group. (Some people also 
say abbreviations are bad because the number of bytes saved is insignificant 
on moden hardware. But I find that to be a bit of a strawman since everybody 
on *both* sides agrees with that and the people who still use abbreviations 
generally don't do so for that particular reason anymore.)

> - Unless very useful, it's better to avoid pointers and to use normal 
> array syntax [].

Heh, yea. Well, that's old-school C for you ;)

>
>>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.
>

Yea, since the book was written, exceptions have pretty much become the de 
facto standard way of handling errors. There are times when exceptions 
aren't used, or can't be used, but those cases are rare (dare I say, they're 
"exceptions"? ;) ), and the most compelling arguments against exceptions are 
only applicable to languages that don't have a "finally" clause.

>
>>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.
>
> 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.
>

Python certainly makes the consequences of getting the index wrong less 
severe than in C, and less likely. But it still stikes me as a bit of a 
"dual-purpose" input, and therefore potentally error-prone.

For instance, suppose it's your intent to get the fifth element before the 
one that matches "target" (and you already have the index of "target"):

leeloo = collection[targetIndex-5]

Then, suppose your collection, unexpectedly, has "target" in the third 
position (either because of a bug elsewhere, or because you just forgot to 
take into account the possibility that "target" might be one of the first 
five). With bounds-checking that ensures no negatives, you find out 
instantly. With Python-style, you're happily givin the second-to-last 
element and a silent bug.




More information about the Digitalmars-d mailing list