March 24, 2014
The right way … ?

So, I want to get things right (and even possibly get something done). But what is right ?

I will try to narrow my vague sense of “good code” into a few categories :

  • Reusable : AKA the UNIX philosophy. Keep your code modular, split large functions into atomic units, let your data flow freely. If you stumble on a good pattern/recipe, abstract it away so you can make use of it somewhere else.

  • Small resource usage : Fast code with a tiny memory footprint is always desirable, especially in the context of re-usability. A few examples of what that means to me:

    • Coding a layer of abstraction should never mean adding overhead to a program.
    • Don’t reinvent the wheel. Search the standard library until your eyes bleed, search already-made packages, but don’t lose time solving problems people have already solutions for. Well, unless your wheel is actually a quantum hypercube. Even then…
    • Always profile your code to find bottlenecks and optimize where it counts, instead of trying to toy around and guess where the problem lies, or spend valuable time prematurely optimizing something only to find out you’ll have to replace it anyway.
  • Extendable : You will go back to your code to add features, so make it easy on yourself. Rather counter-intuitively, that means having clear boundaries on what your code does and does not do - by keeping a clear, accurate and heavily-documented model of the workings of your code so you can easily find the best place and way to implement a new feature.

  • As tiny as possible : The best documentation cannot help a codebase so large it has become unmaintainable. Don’t add features for which there is no actual demand, depreciate and remove features which are no longer used, refactor old code if there is a new, easier way to do it, even if it breaks things in the process. There are languages where backwards compatibility is desired, and Python is not one of them.

March 24, 2014
Python, my way ?

"For what is a programmer, what has he got?
If not his code, then he has naught”
               - frank_sinatra()

Alright, so I figured I should first make a series of posts about the way I write Python and code in general right now, so that I might look back on it later and laugh at how wrong and misguided I was.

One thing will remain true, though : as a programmer and masterful procrastinator, I will always find myself pondering which way of doing a given task is the best - that is, a balance of fast, readable, and beautiful.

Thankfully, the gods of Python have descended from their higher plane of existence to provide guidance to us, lost and confused souls begging for answers : from the Zen of Python, I quote :

In the face of ambiguity, refuse the temptation to guess.
There should be one— and preferably only one —obvious way to do it.

Gee, thanks. That sure helps with not spending all your time on the Internet trying to find out how others are doing a particular thing and why it’s obviously the best.

However, I believe that doing things right is a worthwhile endeavor, because in the process of figuring out the right way, you often delve deeply into the inner workings of what you’re working with, and learn a lot more than what you would have had you simply found a quick solution and moved on to something else.

So, doing things the right way will take more time - but the knowledge that it brings will definitely save you time on reviewing, refactoring, debugging and all those other things which you don’t really like to think about while you first start a project, but actually end up being the biggest part of your time spent working on the code.

(Be careful, though. You can only go so far down the rabbit hole. Any further and you’ll start having the weird urge to write your own programming language - trust me, you don’t want to go there.)

March 24, 2014
Testing markdown codeblocks

woo

Hi
I'm a code block
nice to meet you
what are you doing with that pickaxe
please
oh god
I have a family

another test

backticks ! magic

but different than the other one anyway it looks ugly on the dashboard.

trying custom html:


    9  def sum_pairs_map(acc,t):
    10     return tuple(map(sum,zip(acc,t)))
    11 
    12 def sum_pairs_lc(acc,t):
    13     return tuple(i+j for i,j in zip(acc,t))
    14 
    15 def sum_pairs_mapop(acc,t):
    16     return tuple(map(add, zip(acc,t)))

trying google prettifier magic which will not work in dashboard

    9  def sum_pairs_map(acc,t):
    10     return tuple(map(sum,zip(acc,t)))
    11 
    12 def sum_pairs_lc(acc,t):
    13     return tuple(i+j for i,j in zip(acc,t))
    14 
    15 def sum_pairs_mapop(acc,t):
    16     return tuple(map(add, zip(acc,t)))

getting rid of line numbering, using prettifier for that


def sum_pairs_map(acc,t):
    return tuple(map(sum,zip(acc,t)))

def sum_pairs_lc(acc,t):
    return tuple(i+j for i,j in zip(acc,t))

def sum_pairs_mapop(acc,t):
    return tuple(map(add, zip(acc,t)))

For a reason I don’t understand adding <code></code> blocks inside of <pre></pre> (as suggested by html5) adds one line at the start and at the end of the codeblock (can be removed by not having whitespace between <code> and the start of the codeblock like I did below, but that’s a bit ugly to edit).

def sum_pairs_map(acc,t):
    return tuple(map(sum,zip(acc,t)))

def sum_pairs_lc(acc,t):
    return tuple(i+j for i,j in zip(acc,t))

def sum_pairs_mapop(acc,t):
    return tuple(map(add, zip(acc,t)))

I guess padding is fine anyway. In any case, this will work for now.

By the way, when you select auto-line-numbered codeblocks to copy/paste them it doesn’t copy line numbers ! How cool is that ? Now all we need is better syntax highlighting for python code…

Gonna add credit for the prettifier to the theme footer and start actually writing stuff about python.