All three are designed to differentiate member variables from arguments, constants and properties. Pick one and use it across your project.

I think people spend too much time worrying about formatting issues (say, in code reviews) instead of focusing on the fact the code is wrong/buggy.

Explaining TDD to a naysayer has always been like showing an atom to someone who has a scope that stops at the molecule. Same for solubility, except now the audience is veteran TDD’ers – and that’s really frustrating as there’s an inherent hypocrisy in asking folks to suspend conventional disbelief and just try something new while not continuing to do the same.

Everything new becomes old, and at some point, folks are just going to hold on to a given era and remain there. This is presently the frustration I have with my circle of veteran agilists. Some prop pilots will simply never want to fly a jet – especially if it means a significant investment in yet more learning and re-learning.

I stand by my position on code uniformity – when we’re talking about solubility as a next step after TDD and when practiced in that context.

Code uniformity is about *respect* for your fellow developers, you want everyone to be able to use and maintain the code and you want that in return so everyone agrees on what is important and what’s not. Sure you may hate an indent of 4 but at least you got them to use spaces over tabs. Uniformity to a certain level is *highly* important, you just have to figure out where that point of diminishing return is.

Now if you have that one crazy code-mumbling egotist coder then just smile and nod and forget to invite him to the next standup where you talk coding styles. Sorry crazy guy, you’ve got to give in to the good of the team, not your own ego, so just be happy with your stapler and be quite :)

Pretty much. One man’s battle is another man’s war. ..

Once when I worked at MSFT, I had an architect slap my hand and overnight he refactored all my code to include this. on all variables.

Guess that experience left me with suppressed memories and unconscious mental imprinting that it needs to be done. Something I am picky about, but could easily be placed in the “Don’t care” pile if I was to get over my own neurotic behaviors.

One minor question, why do you say that this.variable should be in the standard but that we shouldn’t argue about m_ or _. Aren’t those the same issue? They are both trying to solve the same problem.

> who should give more, the creator or the
> maintainer?

The maintainer. Maintenance is 80% of software cost BY PHASED DEVELOPMENT. If you have a maintenance phase, and based on common understanding of the distinct place in phased development lifecycle where transition to maintenance happens, the the 80% mark is true.

The reality is that the moment of software creation is so infinitesimally small that it’s barely worth mentioning.

There are two phases of software development in contemporary processes:
1-) thinking about about you’re about to do, and
2-) everything that comes after you’ve thought about it and wrote it down in code.

Once any single byte of code exists, it’s in maintenance – even if it was created only a minute in the past. Software Creationalism says otherwise, and gives rise to the 80% number, but it’s a software cosmology based in an software lifecycle ideology that has proven to be pretty seriously flawed.

> so shouldn’t we allow developers to code
> comfortably?

Absolutely, but that means that they should comfortably work within set constraints. The kind of disciplined software production that leads to levels of agility that come after merely solving the software defect problem with unit testing and TDD depend on this extent of constraint and control – just as does the Toyota Production System that we all hold up as a paragon of agile virtue.

The software developer plays the role of both ideator and production worker. He has to come to terms with the different constraints that apply to software ideation versus software production, and accept that production work isn’t as willy-nilly as ideation tasks.

It’s the attraction to the stream-of-consciousness ideation that permits the entitlement to phased development. It gives some folks on the team the license to do all their work in those contexts that labor under fewer constraints. It’s a selfish and destructive pre-disposition for software developers, and I’m certainly not immune to its temptations and have given in to them on many an occasion.

Ethics, responsibility, and moral imperative suggest that I remain vigilant, however, and part of that vigilance is informed by a practice of the constraints that I’m accountable to.

> I love the ternary operators as they are
> much more “scannable” and express the situation
> quite clearly

Ternary operator statements are less scannable. I look for indents to look for branches and conditional flow control and value assignment. Ternary operators don’t offer the same visual hints to scanning.

Scanning is specifically not reading. Scanning and scannability is more significantly impacted by the geometry of the code and the consistency of the shapes and patterns used to communicate certain kinds of programming concerns.

The significance of a ternary operator to someone who is scanning is that there’s a conditional branch there, and it may very likely be missed because it isn’t shaped like the kind of conditional branch that can be perceived at scanning speed.

Scannability is drive-by readability. If you’ve found a ternary operator statement while scanning, it’s either because you got lucky, or you stopped scanning and switched to reading without taking notices of the change in modes.

If I go from one .cs file to another and they’re formatted differently, but uniformly, I’m less inclined to complain than if they’re all over the place within individual files.

I can adapt to K&R braces or PASCAL braces, I do not want to have waste brain cycles working with both within the same code unit. It’s inefficient.