Anyone here have any solid tips to write better codes? Perhaps better designs?
Any links to articles? I am saying this because although my code are alright, I
want to make it to the point where I am proud to show it to other programmers.
I try to do my best, use smart pointers, follow common guidelines and what not.
But I feel that when I write a "large" project. It starts out like a good design,
IMO, then towards the end it starts to fall. I am not sure why exactly. I start to
hack things together sometimes. Anyone want to suggest anything at all. And please
be nice, you guys are probably getting tired of me, assuming you guys even notice
me a tiny bit. Thank you.
Better coding?
Quote:Original post by ConcentrateThis always happens, to everybody. If you don't want it then you have to fight it by incrementally refactoring your deteriorating design into a better one until you are once again happy with it.
It starts out like a good design, IMO, then towards the end it starts to fall.
Quote:I start to hack things together sometimes.We all do that too.Either because deadlines are approaching, or because we want to rapidly prototype and without the overhead of maintaining a good design at the same time. Once you've reached a hacked-together version that implements everything you need to then work on refactoring it into a clean design. It might even be the case that you can do your hacking in a separate project and, once done, integrate a cleanly re-engineered version into your actual project.
dmatter is quite right. Periodic refactoring is part of the engineering process. Knowing when to do it comes with experience. Recognising patterns that are likely to fail and refactoring them before you hang too much other stuff onto them also comes with experience. I was just thinking today whilst sitting at the keyboard at work (currently refactoring part of my software), that sometimes you have to take 1 step backwards to go 2 steps forwards.
There are a lot of good books on producing quality code, or which explain certain best practices -- Effective C++ and More Effective C++ come to mind (though the later is a bit dated, having not yet recieved a second, more-modern edition), or anything in the Accelerated C++ series of books (They all share a similar red cover), Modern C++ Design, is another book in the series.
Patterns are good to know and apply, just be sure you aren't duped into thinking that there is a "the" pattern. Patterns, as described in several software engineering texts, are not over-the-counter solutions, but rather well known and effective home remedies which are to be applied to suit the specifics of the problem. In other words, a pattern in not a "thing" that can be copy & pasted in, and the problem molded around, it is an approach to solving an existing problem that is already in place. That said, knowing the general properties of the patterns as you design can sometimes help you see the problems you face for what they really are. Also, the Singleton "pattern" is wildly popular among naive young coders, and you may be tempted to fall into the same trap (it has the nefareous property of seeming much more useful than it is, as well as much less dangerous than it is), so just don't. Search "Singleton" in the forum for discussion on why it's so bad.
Refactoring is also key to maintaining code quality, as has been said. Many other practices, when adhered to, also tend to force you to produce better, more thought through code -- const correctness, limited or no global mutable state, chain-of-command, not doing too much in a single function, good naming conventions... Disciplined code (presuming correct disciplines are chosen) is most-often good code.
Patterns are good to know and apply, just be sure you aren't duped into thinking that there is a "the" pattern. Patterns, as described in several software engineering texts, are not over-the-counter solutions, but rather well known and effective home remedies which are to be applied to suit the specifics of the problem. In other words, a pattern in not a "thing" that can be copy & pasted in, and the problem molded around, it is an approach to solving an existing problem that is already in place. That said, knowing the general properties of the patterns as you design can sometimes help you see the problems you face for what they really are. Also, the Singleton "pattern" is wildly popular among naive young coders, and you may be tempted to fall into the same trap (it has the nefareous property of seeming much more useful than it is, as well as much less dangerous than it is), so just don't. Search "Singleton" in the forum for discussion on why it's so bad.
Refactoring is also key to maintaining code quality, as has been said. Many other practices, when adhered to, also tend to force you to produce better, more thought through code -- const correctness, limited or no global mutable state, chain-of-command, not doing too much in a single function, good naming conventions... Disciplined code (presuming correct disciplines are chosen) is most-often good code.
1. Learn to use multiple dissimilar languages to a good standard
2. Don't be afraid to make numerous prototypes. Subsequent revisions tend to materialize faster and are usually better 'designed'.
3. Use tools that promote experimentation (version control)
4. Share code before you're (entirely) happy with it. Being 'wrong' is fine. Moreover, it's fundamentally required for progress, by definition of 'progress'. If you can get others to help you find out where you're faltering, you'll move faster.
5. Try out new technologies and methodologies with eagerness and skepticism in equal measure. Avoid religious alignments to technologies and methodologies.
EDIT:
6. Strive for purity of design and implementation but if an ultimatum forces your hand, don't hesitate to be pragmatic. As time goes on, elegance and pragmatism seem to converge anyway.
2. Don't be afraid to make numerous prototypes. Subsequent revisions tend to materialize faster and are usually better 'designed'.
3. Use tools that promote experimentation (version control)
4. Share code before you're (entirely) happy with it. Being 'wrong' is fine. Moreover, it's fundamentally required for progress, by definition of 'progress'. If you can get others to help you find out where you're faltering, you'll move faster.
5. Try out new technologies and methodologies with eagerness and skepticism in equal measure. Avoid religious alignments to technologies and methodologies.
EDIT:
6. Strive for purity of design and implementation but if an ultimatum forces your hand, don't hesitate to be pragmatic. As time goes on, elegance and pragmatism seem to converge anyway.
One way is to learn about data structures, how they work, and learning how to analyze the complexity of an algorithm using Big(O) notation. This will help you to realize what's more efficient when using certain algorithms/data structures.
Most of the time you won't have to write your own linked lists, trees, stacks and so on but it's good to know how they work and what their magnitude is.
Most of the time you won't have to write your own linked lists, trees, stacks and so on but it's good to know how they work and what their magnitude is.
Don't try to create massive ultimate design and interfaces upfront and then force the implementations to them. I usually have to write stuff at least two times, so I prefer to write fast prototypes that fail fast. Only after few (three?) concrete implementations the requirements for common interface comes more clear.
I suggest you read the cons of Waterfall, and then about different methodologies like iterative and incremental development, rapid application development etc.
Best way to find out the pros and cons of each, is to just test them. All have flaws. Personally I (and our team at work too) change, modify and mix different developement models at different phases of the app dev.
I suggest you read the cons of Waterfall, and then about different methodologies like iterative and incremental development, rapid application development etc.
Best way to find out the pros and cons of each, is to just test them. All have flaws. Personally I (and our team at work too) change, modify and mix different developement models at different phases of the app dev.
First, this.
As far as books go, I've only read Clean Code by Robert C. Martin (that's where I first saw the above comic) but I can recommend it for having good sense (mostly). Some of the suggested refactoring in that book is taken a bit too far (one example ends up with two or three methods broken down into twenty, with one line of code per method).
Some things that come up again and again when people talk about "good" code: Single Responsibility Principle, Open-Closed Principle, Law of Demeter, Test Driven Development.
As far as books go, I've only read Clean Code by Robert C. Martin (that's where I first saw the above comic) but I can recommend it for having good sense (mostly). Some of the suggested refactoring in that book is taken a bit too far (one example ends up with two or three methods broken down into twenty, with one line of code per method).
Some things that come up again and again when people talk about "good" code: Single Responsibility Principle, Open-Closed Principle, Law of Demeter, Test Driven Development.
Quote:Original post by lightbringer
Some things that come up again and again when people talk about "good" code: Single Responsibility Principle, Open-Closed Principle, Law of Demeter, Test Driven Development.
Speaking of which, check out the last couple links in my signature. They are (or point to) links to some good articles about (object-oriented) software design principles.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
