Writing reusable code

RicardoSmith

Any pointers to books, weblinks that give some pointers to structuring and writing code (VB/VBA/ASP) etc to maximise the resusability of the code that you write. I'd like to plan my code better, so that I start with robust code rather than it evolving from bad code as it does at the moment. I know you get this from experience, but somebody somewhere must have sat down and put some ideas/guidlines down to help noobies like myself.

At the moment I sketch out the code on paper and look for commonalities, to minimise the coding and also to improve the structure of the code.

Kernel32

There are a few very important things you can work on to build better and possibly reusable code. Resusable code is a bit of a myth when it comes to business applications because most business problems are just different enough to make it impractical.
I would suggest you focus on reusable patterns and writing maintainable code. There is a ton of information available for free on patterns, even Microsoft has a section devoted to it now, check out...
http://msdn.microsoft.com/practices/default.asp
It is very .NET centric though, but has lots of good information.
If you couple this with writing good code, in the case of VB and ASP that would mean using classes in VB and structured ASP code, like having include files, a standard way of handling security on each page, a standard way of getting data from a data source etc. I have seen thousands of poorly written ASP pages which have no structure and are a maintenance nightmare.

Finally don't be afraid of refactoring code. A lot of programmers will look at existing code that needs to be changed and shy away from changing it, instead they work around it, which creates yet another layer of complexity for the next poor bastard who has to change it. The opposite of this is refactoring the code. The isn't a new idea, it has regained popularity through the extreme programming and adaptive software development movement which is in vogue, and I personally like it a lot. For more information on refactoring check out http://www.refactoring.com/

For information on extreme programming, adaptive software development, agile development, test first programming etc check out Agile Alliance

The end result of using some of these techniques and patterns will be good quality maintainable code which will also be reusable to a certain extent.

boo-boo

Theres tons of stuff on OO-& java frameworks etc. but not so much on VB / ASP. A good one I came across was
Fitch and Mathers Stock 2000 (sorry , don't have a link, its somewhere on the MS site)
an implementation for a VB /ASP and SQL Server framework.
It uses dynamically constructed stored procedures & lots of other useful techniques. its well worth checking out.

ciano

Another decent (-ish) book is 'Refactoring by Martin Fowler'!

flav0rflav

I would suggest you read any book on software design and architecture. My preference would be an Object Oriented Design style. VB/ASP have the ability to be well designed, but they really don't encourage it.

My biggest problem with 'noobies' is that they seem to have no understanding/appreciation of software design/architecture. Do course not cover these aspects of software development?

It's as if you join the army, they give you a gun and get you to shoot it till you're pretty accurate, then they throw you in, not having mentioned anything about team work, strategy, the enemy, the objective etc.

RicardoSmith

Not everyone has the opportunity to do a course...

Kernel32

flav0rflav,

I think for the most part colleges and courses teach programming and technologies. This would allow someone to write code but not know much about developing software and a large amount of developers are in that camp, code writers not software developers. This is very unfortunate because it gives us all a bad name, but it is great to see someone such as RicardoSmith at least recognise that there are better ways to do things and want to learn them.

RicardoSmith

TBH I'm in two minds. I obviously see my own code and think, well there HAS to be a better way of writing THAT! But then on occasion I've had to optimise code to the nth degree and found that the badly written code was easier to modify and work with than the highly optimised code. especially if the application is subject to a lot of change. kinda like the way a high abstracted database is harder to work with than one that isn't. There comes a point where the efficiencies gained in functionality are outweighed by the complexity and effort required to develop and maintain the code.

flav0rflav

Well, hold on a second. Are we discussing well structure code for maintainability, reduced bugs, etc, or optimised code. These are in general conflicting requirements, and as you say, optimising code usually tends to make things more complex. Or is that what you meant.

Is it your intention to write more efficient/optimised code, or, more structured/maintainable code?

RicardoSmith

I think the discussion has moved on from my original query.

Are they mutually exclusive? At my level unfortunately yes. But I would hope that eventually both could be achieveable.

Tenshot

If you're interested in optimising code, read Jon Bentley's Programming Pearls and More Programming Pearls. You should also take a look at The Practice of Programming by Kernighan & Pike.

Generally, the approach is to make sure you have the right algorithm, data structures, etc, before you waste time shaving off the last few CPU cycles by converting everything to hand-crafted assembly.

Sparks

I think if you're looking towards reusable code, patterns are something to look at but not to adopt blindly. Several people have commented that 'learning patterns' is itself an antipattern. The idea behind the original gang of four book was not to teach how to solve a problem, but to give a terminology that we could use to describe the way we solved problems. So saying "I'll go learn the Facade pattern" isn't necessarily the right approach, it's like saying "I'll go learn Language".

If you really want to learn how to write reusable code, go learn encapsulation from OOP, proper API design (there's a good Google tech talk on that), and look over how modular code was written. Once you've learnt that, then design patterns can be useful as they give you terminology to let you discuss your designs with other developers.

padraig_f

Head First Design Patterns is pretty good. It not only describes the patterns but explains the rationale behind why they are used. The main one being: change. Requirements change, understanding of the problem changes etc. And using the design patterns, or those kind of techniques, help your program be more robust in the face of change.

I'm not such a fan of grand upfront design, often you don't understand the problem fully until you start implementing it, and I'm not sure what's so much better about drawing a UML-graph vs. code editor for sketching/refactoring. There's a good essay on it here: Hackers and Painters

For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.

For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.

Sparks

We're resurrecting a zombie thread here, but I suppose there's no harm in this one, it's a decent topic.

[-0-]

I recommend reading The Pragmatic Programmer.

BostonB

The problem with using painters an analogy is that many do actually plan their painting, by sketching them first, and even constructing them on the canvas before painting over it. Many adhere to certain rules. The idea that they simply just started painting then corrected as they went is usually wrong. Thats how not to paint. Thats not to say they don't correct as they go. But they try to avoid that if possible.

As a rule of thumb I'd say I see vastly more problems from software that been designed/constructed on the fly then that which has been planned out beforehand.

EL_Loco

Just finished some VBA I was working on in excel.

I have a "library" module where I place all the functions/subs I have written. I always try and write the code using as many subs or functions as I can which allows me to re-use the code. If you understand what a function is then having a think about how you could write the solution with as many functions as possible.

Sometimes this leads to taking a little bit longer to actually get the solution finished, but the upside is you've written something you can use again.

some things I have written for excel which can be reused:
fill blanks in a column with whatever you pass into the function
if you find a blank cell in a column delete the entire row
if you find data in a cell in a column delete the entire row
cast a column to a certain data type (sometimes the format cells doesn't manage it correctly)
if you find a match on data you're looking for move the entire row to a different sheet.

I suppose in answer to your question, there's no hard rules to it, a little bit planning before you start and a "how do I write this with functions I can reuse" approach throughout. The fact you're actively seeking to write things with re-useability in mind is clearly going to be one of the largest factors for success.

off topic, vba is rubbish for including modules, you've to import them manually each time. There's no "include" statements. really annoying.

BostonB

You can use components or even a exe if its written to accept parameters. Commercial VBA developers use this to hide their code, and distribute the functionality. Handy sometimes if you writing something to ftp something, or perhaps get online data into a local template. Connect to web feed for financial data. Maybe not elegant but it works.