Better code
-
hey guys ! can you guide me ,how can i write code in good ways!? well lemme explain whats my problem ! i thought writing codes is most simple part of developing ,but after some project which i did ,i found that need to change my coding style ! as you know for one porpuse is many way to achieve ! but i found always choose worst way ! well is any book or reference to teach me how i choose best way? at least better way! very thanks :)
-
hey guys ! can you guide me ,how can i write code in good ways!? well lemme explain whats my problem ! i thought writing codes is most simple part of developing ,but after some project which i did ,i found that need to change my coding style ! as you know for one porpuse is many way to achieve ! but i found always choose worst way ! well is any book or reference to teach me how i choose best way? at least better way! very thanks :)
Strive for CLARITY. Bugs tend to appear in unclear code. They're harder to find there too. Maintenance of unclear code is more expensive. Unclear code is unreliable. Try to make your methods short. As a method grows in size, its complexity increases faster than linear. If a method is becoming too large, break it up into 3-5 subroutine calls. Start with designing the GUI. This will guide the rest of the development. Don't feel bad if the approach you took was the worst one, because you'll learn from this experience. All programmers go through this. Try to summarize what you've learned in a simple rule you can follow to avoid this problem in the future.
-
Strive for CLARITY. Bugs tend to appear in unclear code. They're harder to find there too. Maintenance of unclear code is more expensive. Unclear code is unreliable. Try to make your methods short. As a method grows in size, its complexity increases faster than linear. If a method is becoming too large, break it up into 3-5 subroutine calls. Start with designing the GUI. This will guide the rest of the development. Don't feel bad if the approach you took was the worst one, because you'll learn from this experience. All programmers go through this. Try to summarize what you've learned in a simple rule you can follow to avoid this problem in the future.
Alan Balkany wrote:
Start with designing the GUI.
Hmmm, that approach wouldn't help me as I'm writing mostly backend software. :laugh: Cheers!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
-
Strive for CLARITY. Bugs tend to appear in unclear code. They're harder to find there too. Maintenance of unclear code is more expensive. Unclear code is unreliable. Try to make your methods short. As a method grows in size, its complexity increases faster than linear. If a method is becoming too large, break it up into 3-5 subroutine calls. Start with designing the GUI. This will guide the rest of the development. Don't feel bad if the approach you took was the worst one, because you'll learn from this experience. All programmers go through this. Try to summarize what you've learned in a simple rule you can follow to avoid this problem in the future.
well choosing better algorithm doesnt help? in other word, what is good algorithm features?
-
well choosing better algorithm doesnt help? in other word, what is good algorithm features?
Algorithm selection is a more complex topic. A course (or book) on data structures will also cover the most common algorithms used on these structures. These are also graduate courses specifically on algorithms. (If you haven't already studied data structures, you should. It's one of the more important areas that you'll use on all but the most trivial programs.) At the basic level, you need to avoid bad algorithm choices that waste time and/or space. For example, beginners often (inadvertently) use the Schlemiel Algorithm (http://en.wikipedia.org/wiki/Schlemiel_the_Painter%27s_algorithm[^]) which runs in N^2 time (for N items), for tasks that should run in N time.
-
Strive for CLARITY. Bugs tend to appear in unclear code. They're harder to find there too. Maintenance of unclear code is more expensive. Unclear code is unreliable. Try to make your methods short. As a method grows in size, its complexity increases faster than linear. If a method is becoming too large, break it up into 3-5 subroutine calls. Start with designing the GUI. This will guide the rest of the development. Don't feel bad if the approach you took was the worst one, because you'll learn from this experience. All programmers go through this. Try to summarize what you've learned in a simple rule you can follow to avoid this problem in the future.
Alan Balkany wrote:
Start with designing the GUI.
Say what?? I always start with the data model design. I've found that starting with the GUI tends to influence bad practices in the data model or breaks even breaks it to the point where you need to toss it out and start from scratch.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Alan Balkany wrote:
Start with designing the GUI.
Say what?? I always start with the data model design. I've found that starting with the GUI tends to influence bad practices in the data model or breaks even breaks it to the point where you need to toss it out and start from scratch.
A guide to posting questions on CodeProject[^]
Dave KreskowiakDave Kreskowiak wrote:
Say what??
:thumbsup: I very nearly spilled my coffee ...
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
Alan Balkany wrote:
Start with designing the GUI.
Say what?? I always start with the data model design. I've found that starting with the GUI tends to influence bad practices in the data model or breaks even breaks it to the point where you need to toss it out and start from scratch.
A guide to posting questions on CodeProject[^]
Dave KreskowiakThere are many approaches and many problem types. There's no one correct approach for all problems, and each individual has their own style. In each approach (GUI first or data model first), you can make discoveries that invalidate your previous design. Experience lets you anticipate more accurately the needs of the other half, while designing the first half. In this case, I was answering a beginner's question. This person is unlikely to be dealing with a complex data model, and the needs of the GUI would probably be clearer, and would point the direction to go with the data model to support the GUI. In my biased opinion, the primary purpose of an application is to satisfy the users' needs as well as possible, and letting the data-structure decisions steer you into a less-optimal GUI detracts from this.
-
hey guys ! can you guide me ,how can i write code in good ways!? well lemme explain whats my problem ! i thought writing codes is most simple part of developing ,but after some project which i did ,i found that need to change my coding style ! as you know for one porpuse is many way to achieve ! but i found always choose worst way ! well is any book or reference to teach me how i choose best way? at least better way! very thanks :)
-
hey guys ! can you guide me ,how can i write code in good ways!? well lemme explain whats my problem ! i thought writing codes is most simple part of developing ,but after some project which i did ,i found that need to change my coding style ! as you know for one porpuse is many way to achieve ! but i found always choose worst way ! well is any book or reference to teach me how i choose best way? at least better way! very thanks :)
source.compiler wrote:
well lemme explain whats my problem ! i thought writing codes is most simple part of developing ,but after some project which i did ,i found that need to change my coding style ! as you know for one porpuse is many way to achieve ! but i found always choose worst way !
There are a lot of ways to do something, and even we bicker about what is "best". And most of us here will have some "old code" somewhere from years ago that makes 'em go "wtf" today. Always ask an explanation if there's an opportunity to do so.
source.compiler wrote:
well is any book or reference to teach me how i choose best way? at least better way!
You might want to download FxCop; it checks your code using pre-set rules. Another sweet way of learning alternatives is to read existing code (I love meeting new brownfields!) and, again if possible, ask for explanation if something is interesting. Get lots of practice. Start your own open-source project, so that you'll be forced to "maintain" your own code.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
There are many approaches and many problem types. There's no one correct approach for all problems, and each individual has their own style. In each approach (GUI first or data model first), you can make discoveries that invalidate your previous design. Experience lets you anticipate more accurately the needs of the other half, while designing the first half. In this case, I was answering a beginner's question. This person is unlikely to be dealing with a complex data model, and the needs of the GUI would probably be clearer, and would point the direction to go with the data model to support the GUI. In my biased opinion, the primary purpose of an application is to satisfy the users' needs as well as possible, and letting the data-structure decisions steer you into a less-optimal GUI detracts from this.
ok very thanks ... so i need , practice, survey others codes, and start my projects with GUI?
-
source.compiler wrote:
well lemme explain whats my problem ! i thought writing codes is most simple part of developing ,but after some project which i did ,i found that need to change my coding style ! as you know for one porpuse is many way to achieve ! but i found always choose worst way !
There are a lot of ways to do something, and even we bicker about what is "best". And most of us here will have some "old code" somewhere from years ago that makes 'em go "wtf" today. Always ask an explanation if there's an opportunity to do so.
source.compiler wrote:
well is any book or reference to teach me how i choose best way? at least better way!
You might want to download FxCop; it checks your code using pre-set rules. Another sweet way of learning alternatives is to read existing code (I love meeting new brownfields!) and, again if possible, ask for explanation if something is interesting. Get lots of practice. Start your own open-source project, so that you'll be forced to "maintain" your own code.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
so just exprience can show me better ways to writing codes?
-
so just exprience can show me better ways to writing codes?
Start thinking about how "programming" skills overlap with the non-programming things you do. Draw on your experience in the other areas of your life to help you improve. For example, work on your writing. Coding is composition and all the rules you learned about writing well apply to your programming: say what you mean; don't use a 10-cent word when a 5-cent word will do; don't mix metaphors (i.e., models); etc.
-
so just exprience can show me better ways to writing codes?
-
hey guys ! can you guide me ,how can i write code in good ways!? well lemme explain whats my problem ! i thought writing codes is most simple part of developing ,but after some project which i did ,i found that need to change my coding style ! as you know for one porpuse is many way to achieve ! but i found always choose worst way ! well is any book or reference to teach me how i choose best way? at least better way! very thanks :)
-
ok very thanks ... so i need , practice, survey others codes, and start my projects with GUI?
Also study data structures and object-oriented programming.