how to write a program in most professional way.
This is such a broad question it's impossible to answer.
Here's a starting point:
http://www.parashift.com/c++-faq-lite/index.html
I have that page bookmarked and I recommend it.
Here's a starting point:
http://www.parashift.com/c++-faq-lite/index.html
I have that page bookmarked and I recommend it.
sir , you have given me alot of data.
Can you please be a little specific.
how do we write the source code in a professional way is my question.
Can you please be a little specific.
how do we write the source code in a professional way is my question.
if you want a more specific answer you need a more specific question.
EDIT:
to clarify, there are thousands of design patterns, coding practices, and styles you can use. Any combination of which could be considered "professional". This question is impossible to answer.
EDIT:
to clarify, there are thousands of design patterns, coding practices, and styles you can use. Any combination of which could be considered "professional". This question is impossible to answer.
Last edited on
*rubs forehead*
You just rephrased the exact same question.
I really don't know what kind of answer you're expecting. This is the best I can do:
"Professional" code has the following traits:
- the code itself is easy to understand
- it is adequately commented (but not over commented)
- the exposed interface (public members, class hierarchy) is easy to understand and use
- it is flexible
- it is efficient
- it doesn't have lots of redundant code
- it has minimal bugs
- it is expandable
I could go on and on and on, but I know this isn't the kind of answer you're looking for. If you can't give me a more specific question then I'm afraid I won't be able to give you anything better.
You just rephrased the exact same question.
I really don't know what kind of answer you're expecting. This is the best I can do:
"Professional" code has the following traits:
- the code itself is easy to understand
- it is adequately commented (but not over commented)
- the exposed interface (public members, class hierarchy) is easy to understand and use
- it is flexible
- it is efficient
- it doesn't have lots of redundant code
- it has minimal bugs
- it is expandable
I could go on and on and on, but I know this isn't the kind of answer you're looking for. If you can't give me a more specific question then I'm afraid I won't be able to give you anything better.
Disch is right. You can't ask for a specific answer to an unspecific question.
What do you mean by "write"? Coding style? Development practices? Development tools?
It's impossible to answer your question if you yourself don't know what the question is in the first place.
What do you mean by "write"? Coding style? Development practices? Development tools?
It's impossible to answer your question if you yourself don't know what the question is in the first place.
Last edited on
Four things:
Know algorithms and data structures and the canonical way to use both in your language of choice. In C++, it's the STL (and Boost).
Write code that is documented internally. preferably using a markup language like Doxygen: http://www.doxygen.org/ . You won't understand what you wrote or how your classes should be used three months after you write them. And no one else will know your intentions unless they are documented. (I don't know how many times I've looked at code wondering if some odd behavior is on purpose or an accident.)
Write code with adequate unit tests. Use tools such as cppunitlite or my new favorite, Boost Test: http://www.boost.org/doc/libs/1_38_0/libs/test/doc/html/index.html. Unit tests force one to write code that is modular and reusable -- it has to be usable in your program and it has to be usable in a unit test. That's probably more important than actually testing the code. Test driven development (TDD) is a remarkable invention.
Write code that follows the SOLID principles (http://www.davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html). Take any class you have ever written and apply the SOLID principles to them -- you will be amazed at what you learn.
These principles will get you to what Disch is getting at in his list above, plus much more.
One more thing: submit your code for review by your peers. You will never be expert enough that your code cannot be improved by peer review.
Know algorithms and data structures and the canonical way to use both in your language of choice. In C++, it's the STL (and Boost).
Write code that is documented internally. preferably using a markup language like Doxygen: http://www.doxygen.org/ . You won't understand what you wrote or how your classes should be used three months after you write them. And no one else will know your intentions unless they are documented. (I don't know how many times I've looked at code wondering if some odd behavior is on purpose or an accident.)
Write code with adequate unit tests. Use tools such as cppunitlite or my new favorite, Boost Test: http://www.boost.org/doc/libs/1_38_0/libs/test/doc/html/index.html. Unit tests force one to write code that is modular and reusable -- it has to be usable in your program and it has to be usable in a unit test. That's probably more important than actually testing the code. Test driven development (TDD) is a remarkable invention.
Write code that follows the SOLID principles (http://www.davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html). Take any class you have ever written and apply the SOLID principles to them -- you will be amazed at what you learn.
These principles will get you to what Disch is getting at in his list above, plus much more.
One more thing: submit your code for review by your peers. You will never be expert enough that your code cannot be improved by peer review.
Topic archived. No new replies allowed.