The idea of variable prefixes
The idea of prefixes on variable is “very” old. They are used to tell the developer what kind of variable he is using. The first prefix for example is m_ and the conclusion is this variable is a member. When I learned programming we had to give the developer more information in case of a member. Like the type of it like an integer became m_i. Continue reading
These are the slides and comments of a presentation I held for bbv Software services AG.
The presentation is about how we get quality into our code.
Buzzwords: Fokus, frequent measurements, strong team, clean code, pair programming, test driven development, acceptance tests, continuous integration, collective code ownership, team learning.
Senior Software Architect
bbv Software Services AG
urs.enzler _at_ bbv.ch (replace _at_ with @)
Copyright © 2010 bbv Software Services AG
How to get quality into source code – that’s the question I’ll try to answer in this document.
You’ll see what we do at bbv Software Services to get code that is built with inherent quality and why it is important to think about quality throughout the whole development process.
In C# dotnet the class Enum is heavily used. Some geek’s argue that the Enum’s “improve code clarity and and reduce the probability of invalid values. … Enum’s are self-documenting.
I will show you, that Enum’s are in almost any cases just evil.
You don’t believe me? Read on…
Not long ago the Windows Mobile 6.5 Developer Toolkits have been released to public. I want to briefly summarize what is currently available online and provide you some useful links and information about Windows Mobile 6.5 development.
Yesterday, I found an interesting page (in German) describing some of the most important patterns and practices in software development: http://www.clean-code-developer.de/
Although I’m not a fan of wrist bands (see the linked page to see for yourself), I like the page for its short description of patterns and practices like:
- Don’t repeat yourself
- keep it simple stupid
- single responsibility pattern
- separation of concerns
- interface segregation principle
- dependency injection principle
- Liskov substitution principle
- open close principle
- law of Demeter
- principle of least astonishment
- you ain’t gonna need it
- use a version control system
- issue tracking
- continuous integration
- automated tests
- code coverage
- test first
- and some more