There are tons of blogs that provide sample code on the web and I've found them so helpful to providing insight to answers I've been looking for. I would like to thank every one.
But my blog does not provide code. I've been tackling a different side of software development. The side that is filled not with code, but how we think about code, think about why we do what we do.
About source code. Sooooooo subjective. It's lifespan is limited to the development process and is soon turned into byte code by a compiler, never to be seen by anyone outside of development. Source code is like shared painting where everyone has a vision. The locations of brackets, spaces, names of functions, variable, etc. may instill heated debates from almost any group of developers.
My guidelines (only) for myself are:
But my blog does not provide code. I've been tackling a different side of software development. The side that is filled not with code, but how we think about code, think about why we do what we do.
About source code. Sooooooo subjective. It's lifespan is limited to the development process and is soon turned into byte code by a compiler, never to be seen by anyone outside of development. Source code is like shared painting where everyone has a vision. The locations of brackets, spaces, names of functions, variable, etc. may instill heated debates from almost any group of developers.
My guidelines (only) for myself are:
- Stay close to what ever standard your company uses. It's not that big of a deal.
- Don't reformat others code. You would not want them to reformat yours and it really messes up version control duff's.
- Don't enforce a strict format as it can lead to unwarranted confrontation (someone is bound to use a different format).
- When working on others code and providing bug fixes, use their style.
You can tell by looking at source code if the engineer is competent and has interest in the issue. You can also tell if an engineer is not really "into" the issue at hand. Maybe they don't try to mesh with the style or operation being worked on. Maybe they provide a high rate of one-off solutions that degrade the stability of the feature. There are tons of issues with code that is written but for the most part, the only way to change code is written is by changing the way the developer thinks about it and that is a personal issue. People will do almost anything to avoid changing how they think.
For myself it's almost a daily if not hourly review of what I'm doing. My personal review contains simple thoughts like:
- Coding in a non-harmfull way.
- Seeing the code for what is really does (rather than what you want it to do).
- Being mindful of that changes / additions that you do make. Thinking of others.
Just like in fixing bugs where you need to locate the root of the problem, writing code does not start with typing on the keyboard, it starts in your thoughts, desires, problems and hopes.
This is why I do not provide any code in this blog.
Comments
Post a Comment