Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

Above all other concerns to a quality developer is making the software good. Of course, opinions differ as to what constitutes "good" software -- but, there are a few commonalities, ways to make it good:

  • Make it Work
    Software that doesn't work is bad software. Period. Software that works conforms to the design and/or specification, and behaves in predictable ways. This is obvious, but I'd be remiss if I didn't mention its importance. <Update>Of course, while conforming to the design is important, all is for naught if the software doesn't actually run. As FoxtrotUniform and jplindstrom note, sometimes making it work means getting something out the door to the users.</Update>
  • Make it Clean
    The term "clean" can be interpreted a number of ways -- the important thing is that your interpretation fits the realities of your project. Code should be well-abstracted: keep an appropriate separation between method and data. Make sure that you have the rights to any code you reuse. Move code to modules when appropriate. Handle errors, rather than dying.
  • Make it Secure
    Insecure software is rarely useful except as a "throwaway". Be aware of and avoid common security mistakes (like passing formats to printf as user-supplied variables). Respect file locks and permissions, even if you can ignore them. Play nice! Handle errors in a sane way.
  • Make it Friendly
    "Friendly" means different things, depending on context. Whoever will be using and/or administering your final product should find it easy to figure out. Make things intuitive when you can, but remember that not everyone will agree on what "intuitive is". Document well. Keep the interfaces logical and consistent. Don't assume user input will always be valid.
  • Make it Reusable
    There is very little code that will only ever be used once. Move oft-used code into modules. Code with reusability in mind: use constants and globals sparingly, and try not to "code yourself into a corner". Reusable means modifiable.
  • Make it Readable
    Chances are, someday someone else might have to maintain your code. Be sure to use appropriate in-code documentation. Use POD. TMTOWTDI, but be consistent. Structure similar tasks in similar ways. Use indentation, and do it in a consistent manner. Let the flow of your code reflect, visually, the flow of the algorithm.

Of course, as will all "rules", there are times to bend -- and even to break -- the above. Know your project, and let that knowledge guide you.

Update:


As hardburn helped to point out, these should not be construed as "absolute". Compromises have to be made, and made on a regular basis -- that's part of the development cycle. These aren't really "rules" but goals to reach for while coding. It should also be noted that these aren't in any particular order of preference, they are in the order I wrote them down, and that is all.

Also, as with most admonitions, these can be taken too far (except maybe "make it work"). Excessive thrift becomes miserliness; so excessive attention to security, portability, or any number of the other goals can become a poison in its own right.

As dragonchild points out, the first rule, Make it Work, is by far the most important. Lose that one, and you just wasted your time on the others.


Is there anything (else) I missed, or got wrong?

radiantmatrix
require General::Disclaimer;
"Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy

In reply to Make it good by radiantmatrix

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2024-04-24 02:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found