Philosophy and practice of secure programming?

Question

Programming

Hello!
I want to raise the quality of my code to a higher level. Now I'm trying to ensure the quality of my code mainly with the help of TDD and by enabling the "warnings as errors" option in the IDE. I want to deal with two mechanisms that I do not use yet.
The first is assertions (asserts/assertions). They never gave me. As soon as I started using asserts, my code became verbose and unreadable, and I am convinced that unreadable code cannot be considered high-quality and safe. I read about asserts in Code complete, a little bit in Pragmatic programmer and on several blogs. It didn't help, to be honest.
The second mechanism is code contracts. With them, the story is almost the same as with asserts.
As such, I have a few questions:
1. How to apply all these practices together to improve the quality of the code, and not lower it by inept application of practices? (In other words, I'm interested in your opinion.)
2. Are there any articles specifically on the topic of sharing practices? (Ie, the opinion of recognized authorities is of interest.)
3. Is there any specific application of practices if they are used in the development of class libraries, and not applications?

Answer 1

I'll subscribe to the answers, good question =)
As for the assertions, either I don't understand something, or we're thinking about different assertions, but this is a simple function that takes a squeeze, and if it receives a fall, then it displays an error (in different languages ​​differently). Just place them where you doubt the persistence of the data and then view the log.

Answer 2

2x23 + bracket from Ergotron or another manufacturer that will solve the problem of relative positioning of monitors.

Answer 3

If I'm not mistaken, asserts were somehow discussed in Radio-T (together with "escapes" or separately).
Let's assume that this was exactly what happened ... :) Because I remember that this is evil.
In the sense that errors in the program must be intercepted, of course, but processed. And issuing an error message (or writing to the log) is not the best handling option.

Answer 4

asserts should be used in the following case:
There is some (unwieldy) piece of code that has the expected behavior, but due to some circumstances (lack of documentation, obfuscation, lack of experience, insufficient testing, etc.) you can only be 99.99% sure of it. This is evil, but sometimes it happens, especially at the beginning of development. There is a critical operation before which this code is used and for which you need to be 100.01% sure that the code worked as expected, and if it didn’t work, then it’s better to stop the application, because. misoperation may mean, for example, that the memory is corrupted somewhere. There is a way to check that the code worked the way it should. In that situation, when the level of trust in the code is lower than required for a critical operation, an assertion is placed before the critical operation on the result of the code operation.

Answer 5

assert checks those statements that should always be true. If they are not executed, then you have a bug in your code. This is their difference from, for example, exceptions. If your squaring function returns a negative number, what exception should I throw? BadSquareImplementationException? stupidity. But you cannot check that open() did not return a negative file descriptor, since this is a completely normal situation and there is no bug in the code anywhere (even if you created this file in the previous line, someone could have already deleted it).

Answer 6

My opinion - never use asserts in code, as their place is in unit tests. Yes, and the code is cluttered yes.