July Challenge What characterizes a well-written computer program? To start off, here are four characteristics: 1. it works 2. it is readable 3. it uses consistent indentation and spacing 4. it is efficient Who wants to add to this list? Aaron West 5. Has a spec/documentation 6. Meets the spec/requirement(s). 7. Meets a need of at least one user 8. Is portable/deployable to the intended target platform(s) 9. (debatable) Does not duplicate functionality of an existing program, without adding performance or functionality Steve Marland it is maintainable, but that might come from 2 and 3 Lee Bradley 10. well-chosen names for variables, functions 11. comments when they are useful 12. usage help if command tail involved 13. author, date in a comment 14. line count and variable count low 15. build script available 16. sample input and output available Steve Marland Number 9 is a good one, i once had to maintain some code written in a hurry by several people and there was quadruplication of many functions, all just slightly different. Very difficult to maintain Aaron West That's internal duplication, violating DRY (don't repeat yourself). Sometimes it's hard to avoid, due to lack of some types of abstraction in some languages, without writing some sort of macro language or preprocessor. Eg. SQL is a language with limited abstraction facilities, often requiring some repetition, and use of a macro pre-processor is not common. 17. advantage taken of builtin functions of the language Steve Marland Aaron West I appreciate your meaning, but I think this was 4 people each writing their own version of certain needs, so "don't repeat YOURSELF" was probably followed, but "don't repeat OTHERS" was not ;) Tom Gibson I second the motion for all the above, 1 through 17, and maybe more not submitted yet. But I urge #2 above as perhaps most important. I used to say way-way-back when I worked (remember work?), "code should be readable, and if it also worked that was a plus." I would say this mainly to see the reaction of others. Most of my colleagues stressed debugging. OK, we spent most of out time doing that. And that was in the days of punched cards and hex dumps. Achieving #1 was our goal. But if it wasn't readable it was not a contribution beyond the immediate work, and in fact may well be a dis-contribution to that work, especially on team jobs. Steve Marland I second your comments again, readability and doing things in a plain and simple way instead of trying to be clever about it lead to readable and understandable code that leads to maintainability, ie fixability, without too much need for gdb or hex dumps, as well as maintainability in the form of adaptability for changing needs. Lee Bradley Thank you all for contributing to this thread. Rob Leder In general, I wouldn’t call anything well-written that isn’t reasonably optimized (e.g. doesn’t perform some task as O(n) that with a little thought could have easily been O(log n)). Most of what I work on employs a microservice architecture, and in that world I'd say some good development principles would be to avoid tight coupling and unintended side effects, and strive for volatility-based decomposition - isolating core functionality that should seldom if ever change from features that are malleable or expandable. Steve Marland Ah yes, side-effects intended or no, can complicate things immensely. Make a function do its job clearly and without fiddling with other things - for those other things, make specific functions and call them explicitly! Lee Bradley Inspired by Rob Leder's remark, I've been mulling over the Selection Sort post of Danish Arshad. I've been looking at his code and my code and still have not quite figured out if and how they differ. It's not that big a deal of course (Rob Leder and others were addressing the question of what makes a program excellent in the context of large, team-based applications, not standalone simple stuff). So ... the "July Challenge" has now been extended: who is willing and interested enough to look at his code and my code and analyze the differences? My first and second look at his code made me think he's doing more swaps than I am. Lee Bradley And the winner is ... a tie?! I converted Danish Arshad's C++ sort to tiny C and then ran both it and mine a bunch of times. It took between 6 seconds and 9 seconds to sort 200 elements. Of four pairs of runs, two of his were quicker than two of mine (which of course means two of mine were quicker than two of his). I seeded the runs with the same seed for a given pair of runs. I used a different seed for each of the four pairs of runs. http://primepuzzle.com/not.just.tiny.c/ssort.danish.tc http://primepuzzle.com/not.just.tiny.c/ssort.tc