Software Best Practices Training topics required [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

Sorry to post this mundane question here, but I need help!

I have to do a 1 hour Software Best Practices Training for some programmers in my company. Audience are Freshers to couple of years experience guys.

Can you guys please suggest some relevant topi开发者_StackOverflow社区cs I can cover?

I could think of the following:

1) Importance of following coding standards, indentation 2) Proper naming of files, variables, functions, classes, tables, columns, views and all other artifacts 3) Layer your application - each layer must address a specific concern 4) Abstract common stuff into reusable utility classes

Any help will be greatly appreciated (A positive response to this post & I promise I will contribute to the community by replying to at least 10 threads!)

---

The topics you mention are good. If you want to mention each only briefly, and therefore want to add others, you could consider some of (in no particular order):

• automate, automate, automate: boring, repetitive tasks are much better suited to automatic scripts than having them demand user attention. For example, most coding standards (all that can be "mechanically" checked) must be checked automatically by scripts ("lint-like" is the classical name for them) on submission of code to the repository (if you don't have a good source code versioning system drop everything else and focus everything on that, of course, because it's the single most crucial tool).
• testing: automated, and automatically repeatable, unit tests, and integration tests, and continuous-build tools to run them all the time, are a wonderful safeguard against accidental breakage in the codebase.

• mandatory, lightweight code reviews (or pair programming): no code should ever get into the codebase without other human eyes having examined it and approved it -- not to duplicate the "lint-like" part, but to check stuff that's too hard to check automatically -- are the identifiers clear and appropriate, has the refactoring of reusable stuff been done right, &c

  • proper use of comments: they should never repeat what the code already plainly says to anybody who masters the language -- they should add useful, concise info not otherwise immediately handy. A ga bad, a good, and a best example in C...:

  /* bad -- in fact, VERY bad / i += k; / increment i by k */

  /* good, or at least decent;-) / i += k; / widget count grows by thingamajig count */

  /* best */ widget_count += thingamajig_count;

(no comment present nor needed in the the last case -- it's far from always possible to have the code and identifiers be quite so clear as to need absolutely no comment, but, when feasible, it's definitely best!-).

---

This SO link probably has the best answers you could want. One of the opinions is:

The only "best practice" you should be using all the time is "Use Your Brain".

---

Your topics already cover quite a broad field. But going into much programming detail, could lead to the impression that software development best practices are only concerned with coding.

Regular commits with carefully written commit-messages (of tested code) are as important. Which leads to the next topic. Testing. Test your code, reflect about it. Typedef everything (at least in C(++)).

---

In addition to the things you have already listed, I would cover :-

1. Version control strategy - branches / merging / checkin - commit policies etc
2. Commenting standards - based on whatever you follow in your application
3. Refactoring
4. Unit Testing basics -especially for the freshers.

---

If you want your training course to have significant effect, then you want to stick to topics where you can clearly communicate the benefits of each topic, and not just give them abstract rules. Actual data and war stories about how projects failed because some code was misread, bug was too hard to find, other bad practice, etc. are much more memorable to some percentage of students than a bunch of guidelines with no explanation.