Posts tagged 'Better Developer'

Wednesday, September 11, 2013

Coding Guidelines, write well crafted code

Some thoughts on coding rules to apply:

Make your code easy to read...

  1. Implement the SOLID Principles
    • Single Responsibility Principle
    • Open Close Principle
    • Liskov Substitution Principle
    • Interface Segregation Principle
    • Dependency Inversion Principle

  2. Design Guidelines For Developing Class Libraries on MSDN
    • Follow standard to achieve consistency in code base
    • Conventions are powerful
    • Standards make reading code and gleaning additional information easier
    • Enforce with StyleCop for instance

  3. Naming code to convey meaning and ease readability/maintenance/extensibility
    • Read other peoples code and figure out what is good and what is bad
    • Be introspective, look at your code and analyse is it doing what it says its doing
    • With practice improve the readability of your code

  4. Adding meaning to code
    • Name classes, methods, parameters, properties, fields, variables, events show what they hold and or do
    • If you're not happy with the API, write the API you want to see and then implement it
    • Try to write code that expresses its intention clearly

  5. Don't use regions
    • Regions are used to hide ugly code
    • Regions can be used to hide classes that have exploded in size and violate Single Responsibility Principle
    • Next time before adding a region break up the code into separate classes

  6. Throw an exception when their is a runtime error condition
    • Don't use booleans or status codes

  7. Avoid parameters that are booleans
    • Makes for bad readability

  8. Keep the number of parameters to a minimum
    • 2 to 3 params maximum
    • If more parameters, group and create a new object

  9. Warnings are errors
    • Set up build to treat compiler warnings as errors
    • Leaving code that creates error messages is a sign of sloppiness
    • Keep entropy away and keep code organized and clean
    • If you let warnings build up, it spreads everywhere

  10. Encapsulate complex expressions
    • Factor it out into a separate method
    • Instant recognition of the codes intention is good

  11. Avoid multiple exit points from a method
    • At the bottom of the method have just one exit point
    • Have a single entry and exit point

  12. Comments are useless
    • Comments are meaningless noise
    • Write the code to be intention revealing
    • A method name is 100% more effective than a comment
    • XML comments to produce documentation for an API are ok
    • Find a way to write your code without comments

  13. Keep methods short
    • 1 to 10 lines of code is right
    • Refactor larger methods into smaller ones
    • If the method doesn't fit on the screen, it makes it harder to understand and modify

  14. Small classes
    • A class should have only one purpose, one reason to exist
    • Use roles, figure out responsibilities, take full advantage of delegation
    • Have many small objects collaborate to solve a tough problem

  15. Test Driven Development
    • Unit tests
    • Test first
    • 100% Code coverage

  16. Clean Code Developer (German Site)

Posted by Nils-Holger at 6:30 AM with 455 comments.

Tuesday, September 10, 2013

How to become a better developer?

Some thoughts about what is required to becoming a better programmer:



  • Read the documentation, Read the specifications of the language
  • Read Code - Write Code - Teach Code
  • Contribute to open source projects
  • Learn a new language every year
  • You only get better if you challenge yourself, move out of your comfort zone
  • Create a blog, write articles on your blog
  • Work on personal projects, build web applications
  • Get involved in user groups
  • Go to technical conferences
  • Teach code - explain something to a co worker
  • Think deeply about the code
  • Do some programming volunteer work for a non profit organization
  • Deliberately practice coding to reach expert level, lots of practice and focus on improvement
  • Do coding katas, particpate in coding dojos, coding koans
  • Read code to learn: codeplex, github, stackexchange, Google code, decompile
  • Reading code, check for patterns, read the unit tests, configuration files and references
  • Criticize the code, look for code contracts, exception handling, formatting, inheritance or interfaces
  • Read the documentation
  • Learning a new language, framework, get new ideas, learn new ways of solving problems
  • Get a list of tutorials, get a library of technical books
  • Join forums, join groups, read blogs and find some mentors
  • Create new projects and get feeback on your code, code reviews online, peers, fxcop, stylecop
  • Share your code, jsfiddle.net, github gist, email, social networks, screen sharing
  • Pair programming, team code review, self review
  • Get further education, training, certifications
  • Online training, classroom training, conferences, on the job, technical content, workshops, user groups
  • A few hours a week pair a senior developer with a junior developer to implement a new feature
  • Show and tell about your personal projects
  • Daily standups
Happy Programing! :-)
Posted by Nils-Holger at 5:00 AM with 972 comments.