how to build good formatter
Hello all
i need to build formatter , something that takes one format and convert it to different format
now as general programming task there isn't much to it but if i like to take this formatter to
more generic uses it can start to be more complex for example
now i need to build formatter that extract data from hash table im receiving from hash table
and build coma delimited records according the key names . nice and easy to implement
but what if tomorrow they will ask me to extract data from xml structure and build from it some other
delimited records by other condition ... i think you got my point ...
is there any thing in the algorithm / patterns world that give answer to this dilemma?
[761 byte] By [
Meirya] at [2007-11-26 23:39:59]
# 1
The name of the pattern you are looking for is called "Programming" The way that you convert one format to another is you write some code to do that.
Just about the only thing that computers do is convert stuff from one format to another. Compilers convert ascii text into byte codes. Virtual machines convert byte codes into executions. CD rippers convert CD audio byte streams into MP3 files. Players convert the MP3 format into sound. Browsers consume HTML and produce screen graphics. Spiders consume HTML and produce data fragments. Word processors convert keystrokes into documents. And every one of these little specialized format converters is the result of "Programming"
Can you extend your format code that produces comma delimited records from Hash tables into something more general? No doubt you can. Will that generality give the formatter the ability to pull data out of a WORD document - probably not.
Generality - generally considered a good thing - has its limits. The primary one being that the more general you make something, the longer it will take to design it and the longer it will take to test.
You think that perhaps by taking some time to design a more robust system today you will somehow have less work to do tomorrow when they ask you for that XML converter. Perhaps that is true, but if they ask you tomorrow to build a photo editor or something that converts Excel macros into Lisp it is unlikely that the design you do today will help that.
The Extreme Programming geeks have the following advice: Don't write code today that you MAY need tomorrow. IF you don't need the code right NOW, there is a good chance that you will be building an extension that will just have to get ripped out by changing future requirements. The only code you should write today, or any day, is the code that you need right now.
Of course the EP geeks are zelots and one should always water down any advice that comes from a zelot, none the less the advice to not get boged down trying to make your code more robust in directions that are currently unspecified is good.
In short, unless you have some good reason to believe that with high probability you will be asked to extend your code in some direction then don't try to extend your code in that direction.
If you want to look at what people have done in the past to make generalized format converters I recommend that you take a look at the standard unix tool set, grep, awk, sed, troff, lex, yacc,... every last one of them a very nice general tool that only a geek can use because they require that you be able to program in order to get them to do anything.
