Following a series of insights learned and translated (very!) freely from the original text ... and not take ourselves too seriously to let the word Dilbert , mythical character from Scott Adams that all developer for their survival techniques and not only (the other is recommended reading The Career Programmer: Guerilla Tactics for an Imperfect World ) should take into account a large ... perhaps even more than Bruce Eckel!
1. Before you let it run, then make it fast ! This is true even if you are certain that any piece of code is really important and that it will become the main bottleneck of your system. Do not touch that fragment to optimize it. First of all try to get a working system with a project as simple as possible. Only later, if it is not fast enough, think about it. Almost always find that the real problem is not "your" bottleneck. Save time for what is really useful.
2. elegance in coding always pays. It is not frivolous activity. You will hand in a program not only easier to compile and test, but also easier to understand and maintain: and this is where you find the economic value of your work . You may need a little 'first experience to understand this fact, as it might appear that, as you seek to make a smart snippet, you are not really productive. Productivity will emerge later when the code will integrate seamlessly into your system, and even more when the code or the system will be changed.
3. Remember the principle "divide et impera " . If the problem you are facing is too complex, try to imagine what might be the basic operations of the program. Perhaps imagining a "something" to deal with the most difficult parts!
This something is an object and then write code that uses that object. Then analyzed the object and encapsulated within its intricate parts of other objects, and so on.
4. If you have a large block of code that needs to change, begin to isolate the parts that will not change possibly being included in a "class API" as static methods. Next, focus your attention on the code that will change, restructuring it into classes. Thus makes easier the changes as your business maintenance will proceed.
5. Keep the distinct from its creator class user (client programmer ). Who uses the class is the "customer" and does not need nor want to know what happens behind the scenes. Who creates the class must be the expert in designing classes and must write it so that it can also be used by most novice programmers, continuing to behave in a robust application. The use of any library is simple only if it is transparent.
6. When you create a class, use a nomenclature as clear as possible . Your goal is to make the programming interface is conceptually simple. Try to make your names so clear as to make unnecessary comments. To this end, exploited overloading of functions and default arguments to create an intuitive, easy to use.
7. The control allows you (the creators of the class) to make extensive changes in the future that will then be possible without adversely affecting the client code where the class is used. In this perspective, keep everything as private possible, and make public only the class interface, instead of always using the data functions . Make the data public only when you are forced. If users do not need a class to invoke a function, declare it private . If a part of your class must be visible to any classes inherited as protected , provides an interface to functions rather than expose data directly. In this way, the changes implemented will have minimal impact on derived classes.
8. First of all, and if possible write the test code . Even before I write the class and then keep evolving along with the class. Make the automatic execution of your test perhaps through a makefile or by an instrument similar. In this way, any changes can be controlled automatically by running the test code, and errors are immediately detected. Knowing that I have the safety net of the test environment, you will be more likely to make significant changes when they feel the need. Remember that the major improvements in programming languages \u200b\u200bcome from internal controls provided by type checking, exception handling, and so on, but these features are to a certain point. You have to get down the road that leads to the creation of robust systems by introducing the tests that verify the specifics of your class or your program.
9. Remember a basic rule Software Engineering: All the problems of software design can be simplified by introducing an extra level of dereference conceptual. This idea is behind the ' abstraction, the primary feature of object-oriented programming.
10. Make the most atomic classes can in other words, give each class a single clear purpose . If your classes or your system design becomes too complicated, break complex classes into simpler classes. The most obvious sign of this is exactly the same size: if a class is large, there is the possibility of doing too much and then you need to analyze it.
11. Beware long method definitions. A long and complicated operation is difficult and expensive to maintain, and is probably trying to do too much alone. If you are to handle such a function, means that, at least, should be divided into several smaller functions. It could also suggest the creation of a new class.
12. Beware long argument lists. Function calls are hard to write, read and maintain. Rather, try to move the method in a class which is most suitable, and / or pass an object as a parameter.
13. Do not repeat yourself . If a piece of code appears in many functions in derived classes, move that code into a single function in the base class and call the functions of derived classes. Not only save space, but allow easy propagation of changes. You can use an inline function perl'efficienza. Sometimes, the discovery of this common code brings considerable benefits to the functionality of your interface.
14. Beware of instructions switch or the if-else concatenated. Typically, this is a clear indicator of the type of programming type-check . Programming
type - check means that you are choosing what code to run under some kind of type information (the exact type could not be immediately apparent). Usually, you can replace this kind of code using inheritance and polymorphism, the polymorphic function call to perform the type check for you, and allow for a more affordable and easier extensibility. [NDT - In reality, the type checking is characteristic of the C + + is a strongly typed language, but the principle is still valid as a point of attention of a general nature in the sense that an excess of if-else statement nested is certainly index entropy high you are entering in the code.]
15. Look limitations in the inheritance . Projects cleaner add new features to those inherited. Beware of a project that removes the old functionality (while you are inheriting) without adding more. But rules are made to be broken, and if you are working with an old class library could be more efficient to restrict an existing class in its subclasses, rather than restructure the hierarchy so that your new class you go to where it should enter, above the old class.
16. not to extend the core functionality in subclasses . If an interface element is essential for a class should be in base class, and not be added during the derivation. If you are adding methods through inheritance, perhaps you should rethink the project.
17. Less is more. Started by minimal interface for the class, simple and small enough to solve your current problem, but do not try to anticipate all the ways in which your class could be used . At the time of use, you will discover the way in which you have to expand the interface. However, once the class is in use, you can not modify the interface without disturbing the client code. If you need to add more features, all right, will not create problems with the code, if not the need for recompilation. But even if the new methods replace the functionality of the old ones, let alone the existing interface (if you want, you can combine the functionality in the implementation below). If you need to expand the interface of an existing function by adding new topics, leave the existing arguments in order, and assign default values \u200b\u200b to all the new ones, in this way, you will not create any problems to call existing that function.
18. Overloading of operators is only "syntactic sugar " a different way to call a function. If overloading an operator does not make the class interface clearer and easier to use, do not. For a class create a single operator for the automatic conversion type.
19. Do not worry about premature optimization. It is pure folly . In particular, do not bother to force the code to be efficient when you are just building the system. Your main aim is to test the project, unless it requires the same degree of efficiency.
20. Keep the scope as small as possible, so that the visibility and the life of your objects are the lowest possible level. In this way, you decrease the possibility of using an object in a wrong context, and to hide a bug hard to find.
21. Avoid, avoid, avoid as much as possible ... we will never tire of repeating, the global variables. Always try to insert data into classes. It is more likely to run into global functions rather than global variables, even though you might realize later that a global function would be a more appropriate location static as a method of a class.
22. Take advantage of your benefit check for errors made by the compiler. Compile your code enabling all warning, and correct your code inmodo to eliminate them all. Write code that uses the errors and warnings at compile time rather than code causing runtime errors. Use assert for debugging, but to use the runtime exceptions.
23. Favorite compilation errors to runtime errors. Try to handle an error as close as possible to the point where there was . It is preferable to handle the error at that point rather than throw an exception. Catch the exceptions in the handler closer than having enough information to handle them. Do everything you can with the exception to the current level and if this does not solve the problem, rilanciatela again.
24. not create your own notation "custom" for the names of member variables ( underscore , prefixes, imaginative variations of Hungarian notation, and so on), unless you have a lot of pre-existing global variables; if not, let the classes and namespaces do the job for you.
0 comments:
Post a Comment