Posts Tagged "Coding"

Duplication in your code. Also, duplication. And duplication.

»Posted by on Sep 24, 2009 in Blog, Coding, Technology thoughts | 0 comments

Duplication in your code.  Also, duplication.  And duplication.

From the department of redundancy department, IT coder division: Duplication is probably the single, most important thing to banish from your code. Duplication can take several forms:   textual This is the simplest and often the easiest to find. This is when you have sections of code that are identical or nearly so. This is often a result of copy & paste programming. Several techniques can be used to eliminate it, including: extracting methods and reusing them, making a method into a template method, pulling it up into a superclass, and providing the variations in subclasses, and other basic refactorings. See Fowler’s “Refactoring” for more detail. functional This is a special case of textual duplication and is present when you have multiple...

read more

Pretty framework, same old code

»Posted by on Aug 22, 2009 in Blog, Coding, Technology thoughts | 0 comments

Pretty framework, same old code

Are you a fad-follower?  Do you always use the latest new development environment simply because it’s this year’s model?  Here’s my axiom: Application architecture is less than optimum if it dogmatically conforms to a trendy framework at the cost of following good design/implementation practices. For example, is it correct to be inflexible and use private fields and getters/setters for a simple data structure (e.g. a DTO)? If a field is transparently readable and writable why not simply make the field public? In most languages you can do that. Granted, in some you can’t. For example, traditionally in Smalltalk all fields are private and all methods are public.In general it’s a good thing whenever you can throw out, or avoid writing, some...

read more

Code formatting

»Posted by on Aug 18, 2009 in Blog, Coding, Technology thoughts | 0 comments

Code formatting

Code should be easy to read. Code should be convenient to read, not convenient to write. There are several things involved here. Choosing good names that are self-explanatory is a good place to start. Strive for simple solutions, even if they are more verbose or inefficient. Whether inefficiency is a problem won’t be known until profiling is done later in the project, in a real production situation. Choose style and formatting conventions early in the project, and conform to them. Require that everyone conform to them. This will be easier to do if everyone has a hand in deciding on the conventions and buys into them. This will make the code uniform and thus easier to read. And get rid of any and all duplication. Do you format your code?  Your queries?  Using...

read more

Functional specs? Anybody? Bueller?

»Posted by on Aug 14, 2009 in Blog, Coding, Technology thoughts | 0 comments

Functional specs?  Anybody? Bueller?

 OK, so you decide to add tests to your code. That typically isn’t so easy. The odds are that your code wasn’t designed and/or implemented to be easily testable. That means you will have to make changes to it to make it testable without breaking any of it (this is usually called refactoring these days). But how can you quickly and easily tell if you’ve broken anything without that comprehensive set of fine-grained tests? Tricky. It’s even trickier than that. If you take the approach that you’ll write tests for all your code after you write the code, you have to go to extra effort to try and design/write the code to be testable.Maintaining an adequate level of testing when writing tests after the code being tested takes time and planning. And if you have...

read more

Code testing

»Posted by on Aug 11, 2009 in Blog, Coding, Technology thoughts | 0 comments

Code testing

Does your code work?  How do you know?  Can you prove it? If you don’t have tests for your code, it sucks. And I mean comprehensive, fine grained, programmer tests (aka something like unit tests), as well as higher level functional and integration tests. Tests that are automated. Tests that are run routinely. With the programmer tests run after any change to the code. Without adequate tests (in terms of both quantity and quality) you simply can’t have confidence that your codes works as required. And even if you are confident with your work, why should anyone else be? What about people who work on the code later? How do they know it still works after they make their changes? Of all the tools and methods out there, which are your favorite?  What is the least...

read more