Exercises in Programming Style–Monolith

NOTE : read the rest of the series, or check out the source code.

If you enjoy read­ing these exer­cises then please buy Crista’s book to sup­port her work.

exercises-prog-styles-cover

Fol­low­ing on from the last post, we will look at the Mono­lith style today.

 

Style 3 – Monolith

As the name sug­gests, this style is typ­i­fied by the use of one big blob of code that con­tains all our appli­ca­tion log­ic!

Constraints

  • No named abstrac­tions (i.e. no methods/functions)
  • No, or lit­tle, use of libraries

 

The first con­straint meant that we can’t break up the log­ic into small­er func­tions, hence why every­thing is inside one big for loop.

I took the sec­ond con­straint to mean that we should lim­it the num­ber of name­spaces we open (as is the case in Crista’s ver­sion). Which means a Dic­tio­nary is out of the ques­tion. I could still use a Map but that feels too much of a cheat so I decid­ed to stick with an array of string * int tuple to keep track of the word fre­quen­cies.

 

First we need to load the list of stop words:

image

Then we read the text line by line and process it in one giant for loop…

image

One caveat I ran into whilst work­ing on this, is with the behav­iour of File.ReadAllLines. It removes the line end­ing char­ac­ter for each line, which means whilst look­ing for words in a line we have two cas­es:

  1. words in the mid­dle of a line, e.g. “I spoke to Eliz­a­beth today…”
  2. words at the end of a line, e.g. “…turned around to Eliz­a­beth

so to make the log­ic con­sis­tent, and remove the spe­cial case (case 2) I decide to just add the new­line char­ac­ter at the end of the string we need to process.

 

Oth­er than the above caveat, this code is pret­ty sim­ple. I decid­ed to devi­ate from Crista’s imple­men­ta­tion in anoth­er place – her solu­tion reorders the word_freqs array when­ev­er an exist­ing word count is updat­ed. But I fig­ure it’s like­ly more effi­cient to just do it once after the main loop.

image

 

side­bar: I have used high­er-order func­tions in a few places, which I’m not sure if they con­sti­tute as cheat­ing. How­ev­er, I don’t con­sid­er them vio­la­tions to the con­straints we have set our­selves for this par­tic­u­lar exer­cise.

 

Conclusions

Code writ­ten in this style is gen­er­al­ly hard to fol­low as you need to keep the entire appli­ca­tion log­ic (i.e. the big for loop) in your head whilst try­ing to under­stand its behav­iour, and we know our brains are not great at hold­ing many items in the active mem­o­ry (the famous 7 +/- 2 rule).

 

One thing to note is that, whilst this style was com­mon­place with low-lev­el lan­guages (and goto was pop­u­lar back then too), it’s pos­si­ble to pro­gram in this style with high-lev­el lan­guages too (as we’ve done with F# here).

I also find Node.js style call­backs tend to lend them­selves to this style of cod­ing too.

 

You can find all the source code for this exer­cise here.