C# Programming Guidelines
作者：袖梨
2022-07-02
source:
this article is from a book named,if you are interested in the book,you'd better to have a real book made by paper :)
Thinking in C#
Larry O’Brien and Bruce Eckel
Prentice Hall
Upper Saddle River, New Jersey 07458
www.phptr.com
begin:
C[
This appendix contains suggestions to help guide you in performing low-level program design, and in writing code.
Naturally, these are guidelines and not rules. The idea is to use them as inspirations, and to remember that there are occasional situations where you need to bend or break a rule.
Design
1. Elegance always pays off. In the short term it might seem like it takes much longer to come up with a truly graceful solution to a problem, but when it works the first time and easily adapts to new situations instead of requiring hours, days, or months of struggle, you’ll see the rewards (even if no one can measure them). Not only does it give you a program that’s easier to build and debug, but it’s also easier to understand and maintain, and that’s where the financial value lies. This point can take some experience to understand, because it can appear that you’re not being productive while you’re making a piece of code elegant. Resist the urge to hurry; it will only slow you down.
1. First make it work, then make it fast. This is true even if you are certain that a piece of code is really important and that it will be a principal bottleneck in your system. Don’t do it. Get the system going first with as simple a design as possible. Then if it isn’t going fast enough, profile it. You’ll almost always discover that “your” bottleneck isn’t the problem. Save your time for the really important stuff.
this article is from a book named
Thinking in C#
Larry O’Brien and Bruce Eckel
Prentice Hall
Upper Saddle River, New Jersey 07458
www.phptr.com
begin:
C[
This appendix contains suggestions to help guide you in performing low-level program design, and in writing code.
Naturally, these are guidelines and not rules. The idea is to use them as inspirations, and to remember that there are occasional situations where you need to bend or break a rule.
Design
1. Elegance always pays off. In the short term it might seem like it takes much longer to come up with a truly graceful solution to a problem, but when it works the first time and easily adapts to new situations instead of requiring hours, days, or months of struggle, you’ll see the rewards (even if no one can measure them). Not only does it give you a program that’s easier to build and debug, but it’s also easier to understand and maintain, and that’s where the financial value lies. This point can take some experience to understand, because it can appear that you’re not being productive while you’re making a piece of code elegant. Resist the urge to hurry; it will only slow you down.
1. First make it work, then make it fast. This is true even if you are certain that a piece of code is really important and that it will be a principal bottleneck in your system. Don’t do it. Get the system going first with as simple a design as possible. Then if it isn’t going fast enough, profile it. You’ll almost always discover that “your” bottleneck isn’t the problem. Save your time for the really important stuff.
