Showing posts with label Pragmatic Programmer. Show all posts
Showing posts with label Pragmatic Programmer. Show all posts

Thursday, October 28, 2010

Code Generation in Ruby

While doing the code generation exercise (chapter 3, code generators) in the book The Pragmatic Programmer, I realized it quickly that C# isn't the best language to do code generation. The main block was that it is too verbose to do regular expression on strings. I had to use Regex.IsMatch and then Regex.Split to get the the tokens. Thats when I looked into ruby.

Regular expressions is a built in feature of Ruby, put between two forward slashes (/). You can use =~ operator for a regex match which sets the special variables $~.  $& holds the text matched by the whole regular expression. $1, $2, etc. hold the text matched by the first, second, and following capturing groups. Some good info here.

class CSharpCode
 def BlankLine
  print "\n"
 end
 
 def Comment comment 
  print "// #{comment}\n"
 end 
 
 def StartMsg name
  print "public struct #{name} {\n"
 end
 
 def EndMsg
  print "}\n"
 end
 
 def SimpleType name, type
  print "\t#{type} #{name};\n"
 end
 
 def ComplexType name, type, size
  if(type == "char[")
   type = "string"
   print "\t#{type} #{name};\n"
  end
 end

end

if __FILE__ == $0
 unless ARGV[0]
  print "cml usage: cml Input.txt\n"
  exit
 end

 if(File.exist?(ARGV[0]))
  CG = CSharpCode.new
  File.open(ARGV[0]).each_line { |line|
   line.chomp!;
   
   if(line =~ /^\s*S/)
    CG.BlankLine
   elsif line =~ /^\#(.*)/
    CG.Comment $1
   elsif line =~ /^M\s*(.+)/
    CG.StartMsg $1
   elsif line =~ /^E/
    CG.EndMsg
   elsif line =~ /F\s*(\w+)\s*(\w+\[)(\d+)\]/
    CG.ComplexType $1, $2, $3
   elsif line =~ /^F\s+(\w+)\s*(\w+)/
    CG.SimpleType $1, $2
   else
    print "Invalid line"
   end
  }
 end
end

Input File
 # Add a product
 # to the 'on-order' list
 M AddProduct
 F id   int
 F name   char[30]
 F order_code int
 E
Output
//  Add a product
//  to the 'on-order' list
public struct AddProduct {
 int id;
 string name;
 int order_code;
}

Friday, July 30, 2010

Repeat - Don't Repeat Yourself!

I am reading The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas and I'm sharing my thoughts, questions, confusions and insights as I continue to read the book.

I have folders on my computer with same books, music, software, photos at more than one location. I routinely copy things (my idea of backup) and then would forget about it. Even my Linqpad queries (which I write to test and learn new code) are at more than one place (office, home, usb, Dropbox) and I can bet they are all different. When working on a active project I knew things start looking bad when I start repeating the same logic at more than one place. Now I have repeated myself a lot of times to make it clear that I do repeat things :)

I did attended object-oriented analysis and design classes in my uni days where you learned how to reuse code and good design principles. But, hey, no one told me to... well... not repeat myself! At least not in plain english. No one told me "DRY—Don't Repeat Yourself" when writing programs as that would have been a better advice.

At work the number one reason of repeating some things would be "Impatient Duplication" - time pressures - forcing us to take shortcuts. But, then again, I have spent many hours correcting something which could have been avoided by not repeating it. 

This is one of the first tips which seems to have influenced me. I did cleaned my PC today of duplicated folders. For stuff where I think I need history, I am making use of Subversion. Eliminating all duplication would be a hard task, but I am on it. Now repeat 10 times "DRY—Don't Repeat Yourself", as you know, repetition is the mother of learning!

Thursday, July 22, 2010

This is what we do

I am reading  The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas and the very first page strikes a chord with me. I hope to learn and share few things as I read the book.

Programming is a craft.

At its simplest, it comes down to getting a computer to do what you want it to do (or what your user wants it to do).

As a programmer, you are part listener, part advisor, part interpreter, and part dictator. You try to capture elusive requirements and find a way of expressing them so that a mere machine can do them justice.

You try to document your work so that others can understand it, and you try to engineer your work so that others can build on it. What's more, you try to do all this against the relentless ticking of the project clock.

You work small miracles every day.

It's a difficult job.