Category Archives: Maintainability

A typical effect of setting CopyLocal = true

If you read me in the past, you certainly know that I have a problem about the Visual Studio default option that set CopyLocal = true in project references assemblies. I mean this option: I’ve already explained the problem in … Continue reading 

Also posted in Acyclic componentization, Code Dependency, code structure, Code visualization, CopyLocal syndrome, Dependency Cycle, Dependency Graph, Dependency Matrix, graph, Graph of Dependencies, Lines of Code, Partitioning, Visual Studio, VS, VStudio | 22 Comments

Don’t assign a field from many methods

For the next NDepend version, amongst plenty of cool stuff, a new default code rule will be added. It has been named Don’t assign a field from many methods. It falls into the category of Purity – Immutability – Side-Effects rules, one of my preferred set … Continue reading 

Also posted in C#, high cohesion, Immutability, measurement | Leave a comment

Ruling Code Quality Regression

A prominent characteristic of the software industry is that products are constantly evolving. All modern development methodologies prone that a product should evolve through small iterations. Internally, development teams are using Continuous Integration servers that shrink increment length to a … Continue reading 

Also posted in API usage, CC, Change summary, Code, code base snapshot comparison, Code Diff, Code Query, Code Rule, code structure, CQLinq, Full Coverage, Immutability, Lines of Code, LINQ, NDepend, software metric, Software Quality Measurement | 1 Comment

Maintainability, Learnability, Component, Layering

Normal 0 21 false false false FR X-NONE X-NONE The last ayende’s post contradicts everything I know about software. Ayende goes against the idea that maintainability can be measured by how easy it is for someone unfamiliar with the code … Continue reading 

Also posted in Ayende, Component, Layering, Learnability | 7 Comments

Re-factoring, Re-Structuring and the cost of Levelizing

I think there is a clear distinction between re-structuring and re-factoring code. This is because of the nature of the OOP code which is made of 2 distinct artifacts: methods’ bodies and fields on one hand, and methods’ declarations, types’ declarations, namespaces’ declarations on the … Continue reading 

Also posted in .NET assemblies, Acyclic componentization, Afferent Coupling, Graph of Dependencies, Layer, Layering, Partitioning, re-engineering | 8 Comments

Dealing with Code Un-Coverable by Tests

Code UnCoverable by Tests Even for test-coverage addict (as me), there is some code that simply cannot be covered by tests. An example? The call to MessageBox.Show() cannot be tested automatically since it is blocking. Of course we could mock calls to MessageBox.Show(), … Continue reading 

Also posted in Code Coverage, Code metrics, CQL, CQLinq, LoC, measurement | 7 Comments

The Open/Closed Principle on MSDN

My latest article entitled The Open Closed Principle is available in the June 2008 edition of MSDN Magazine.  I tried to present both the motivation for following the OCP and some design strategies (besides the obvious Plugin example) and related … Continue reading 

| Leave a comment

Put Code Where You Would Expect to Find It

  I’m going to propose a new design concept with an admittedly awkward name called the “Put Code Where You’d Expect to Find It” Principle.  It means exactly what it sounds like.  A team should strive to consistently put different … Continue reading 

| Leave a comment

Jeremy’s Fourth Law of Test Driven Development: Keep Your Tail Short

One of the first ongoing lesson for making Test Driven Development succeed for you is to learn how to write isolated tests with less effort.  My Fourth Law of TDD is all about recognizing the need to do testing piecewise … Continue reading 

| Leave a comment

The Don’t Repeat Yourself Principle and the Wormhole Anti-Pattern

Getting back on track with the "Maintainability" series of posts.  I'm doing this way too late at night, so the coherence might be lacking. Don't Repeat Yourself Don't Repeat Yourself (DRY) is a statement exhorting developers to avoid duplication in code.  … Continue reading 

| Leave a comment