Exercises in Programming Style

https://henrikwarne.com/2018/03/13/exercises-in-programming-style/

by henrik_w • 8 years ago

381 55 8 years ago

There is also an example with types, but this becomes very awkward to show in Python.

With the book having been published in 2014, and type hints [1] being introduced with Python 3.5 released in 2015 [2], without knowing how the book did it I guess this is one part of the book that could have been made better in 2018.

[1] https://docs.python.org/3/library/typing.html

[2] https://www.python.org/downloads/release/python-350/

tom_mellior3• 8 years ago

As as understand it, those hints are only hints to human readers. There is no standard tooling that actually does any type checking, either statically or dynamically (although such tooling can be built using Python's reflective capabilities). So while adding the hints may be valuable documentation, it wouldn't solve the problem of "showing how types protect against errors in the Adversity section".

gtklocker• 8 years ago

There's mypy.

bringtheaction2• 8 years ago

Like the other commenter said, check out mypy.

http://mypy-lang.org/

faitswulff2• 8 years ago

I am planning on adding this book to my wishlist, but I agree with the reviewer's note at the end:

My only criticism of the book is the naming of the styles...In many cases, there are already establish names for the styles, but instead of using them, the author came up with her own. For example: Trinity instead of MVC, Things instead of Objects, Hollywood instead of Callbacks, Bulletin Board instead of Pub/Sub and Kick Forward instead of Continuation-passing. Those names are OK, but it is much better to stick to the industry standard ones.

I'd definitely include this change in a 2018 edition, too.

kerkeslager3• 8 years ago

MVC = Model View Presenter? Objects = Structs or Workers? Callbacks = Continuations? Pub/Sub = Observer pattern?

Depending on what programming language background you come from, you may not use the "established" names either.

mdpopescu• 8 years ago

That was intentional, see [1]

[1] https://youtu.be/Gw4WJJoDl3U?t=14m30s

gabriel• 8 years ago

I believe the premise of the book is to expose the reader to an element of style that bridges different programming environments. Thus, "style" here is meant more in the terms of a restrictive technique to allow an exposure of these techniques, not writing in idiomatic, or latest-and-greatest Python.

I'd suggest this book even to experienced engineers to focus on different types or a style of programming that he/she may not be familiar. And when you recognize some of the styles it'll be a re-enforcement technique that you were doing something that is seen over and over again (much like a pattern language). I recall going over styles that are seen more in systems programming (like C). The book will contribute to an understanding of code architecture styles across different languages.

For the new engineer, I'd also highly suggest this book as you may begin to see a variety of ways to solve a problem. And I would not concern myself with idiomatic Pythonic styles as that will come with time.

jboynyc• 8 years ago

The author of this book launched a new open access journal called The Art, Science, and Engineering of Programming last year. Professor Lopes serves as editor-in-chief. Much like the book, the journal focuses on the practice of programming and its styles.

http://programming-journal.org/

rs86• 8 years ago

Amazing stuff!

mathieubordere• 8 years ago

Thanks for this! Added to my reading list ...

harel6• 8 years ago

This is very interesting. Not completely unrelated, a friend once told me he can tell a lot about the personality of a person by looking at their code. Years later I actually understood what he meant. Style does have some correlation with personality. Psychology of code...

meuk3• 8 years ago

Can you give some examples of how personality traits manifest themselves in code?

DJohnBenton• 8 years ago

That sounds kind of fun, can you give some examples?

henrik_w• 8 years ago

Maybe not exactly, but this was recently in the news:

"De-anonymizing programmers from executable binaries"

https://news.ycombinator.com/item?id=16598962

harel6• 8 years ago

It's quite hard to examplify once I actually think about an example, but I'll try. It's more a global vibe of a piece of code rather then semantics but they do play a part (using Python as example):

A young person (say 24), has experience coding of a few years, but very enthusiastic, loves reading programming blogs, a real stickler of doing it the "right" way, and sometimes forgets other people might have to read their code. They are not as pragmatic as they would be 10 years down the road. They would use vim or emacs in vim mode because that's more pro. Their code might have a good few "clever" one liners that do something complex in a very concise manner. Took a while to compress into a single line and will take a week to read back and understand. Clever, but only if it never breaks or never needs maintenance. They write factories, sometimes of factories. They have 110% test coverage, including trivial stuff that doesn't require it. They would refactor a piece of code many times until it feels it's the right shade of clever. I like these coders because I can learn something from them, but if you have tight deadlines they might actually get in the way. Great to have a couple of these in your car, but don't let them drive.

    from itertools import chain
    first_set = set(['one', 'two']).union(set(chain.from_iterable([next.key for next in some_yielding_iter()])))
    other_value = make_value_factory_factory(first_set).make_value_factory()

10 years down the line these guys realise you write code once and it's read many times over, and the above turns into a more vanilla multi line readable expression of the same idea.

A less enthusiastic version of said 24 year old, codes because they knows how to, but has no aspirations to get better at their craft. Less organised individual. Pep8 is a new variation of Pepsi Cola? They are not bad coders, just sloppy. Their code works but can be better. They would benefit pairing with the above person.

    def someFunction(value):
        if (type(value) == ThisClass):
            processObject(value)
        elif (type(value) == str):
            processString(value)

After pairing, maybe they were inspired a bit. Maybe they refactor to this:

    from functools import singledispatch

    @singledispatch
    def process_value(value):
        process_object(value)

    @process_value.register(str)
    def _(value):
        process_string(value)

    def some_function(value):
        return process_value(value)

I think a good exercise is to look at a person you know and try ot match their personality to the code style. Then look at some code which might or might not be theirs and try to assert if it is.

segmondy• 8 years ago

Rubbish. Style has to do with habits picked up along the way. Nothing more nothing else. Stop with the psuedo science. When programming in the large (Enterprise). My style is Javaish very long names reactivateSuspendedUser().

When coding for myself, I prefer snake case to camel case and shorter variable names.

Likewise in code, For work, I abstract and decouple to keep the code open for future updates. For personal code, I write throwaway code. Given 2 classes that I have developed for work or play. You will not be able to tell it's from the same person.

n4r92• 8 years ago

I think you're too quick to dismiss. All that your examples prove is that your personal preferences are different to business style code. The fact that you prefer snake case, shorter variable names and throwaway code is quite telling; I enjoy programming puzzles like Advent of Code, and I always use long names in camel case and try to never repeat code. I find that it reduces the mental load and allows me to confidently code faster.

Also it's not pseudo-science. There are real, live techniques for identifying programmers based on binaries:

https://arxiv.org/pdf/1512.08546.pdf

harel6• 8 years ago

You're taking this too seriously. This is not even pseudo science. Just Pseudo.

kerkeslager3• 8 years ago

Yeah, I'd go further and say that preferences only should come into play early in a project when you're deciding on what the style of the project should be. For most of the lifetime of a project, writing in a style that is uniform with the rest of the codebase should come before your personal style.

acbart• 8 years ago

This sounds like it's gearing up to some Myers Briggs or Learning Styles garbage. I don't think you'll get very far with correlating personalities with code. I think you might be able to learn some temporary behavioral traits by studying code, but nothing like a "personality".

mannykannot• 8 years ago

This sounds like a very interesting book. The one small concern I might have (I have only read the review) is that the sample problem might not be a good case for some of the more complex techniques, such as introspection and metaprogramming. I think we have all seen code that seems to have been designed primarily to showcase all of its author's knowledge regardless of whether it helps, and I would not want the book to be misunderstood as an endorsement of that practice.

wickedwizard• 8 years ago

I had this book as a student of Prof Lopes' class at UCI. One of the best classes I had. Programming patterns/styles that senior programmers got through experience were covered, which I liked a lot. As students we had to compulsorily buy the book though.

pjmorris• 8 years ago

I like the review author's approach of writing his own version of the task before reading, then looking for its closest match among the presented styles.

tzs• 8 years ago

Note: its available on Safari Books Online. I would guess that a fair number of people here have SBO subscriptions.

ahjones• 8 years ago

The code associated with the book is all on Github: http://github.com/crista/exercises-in-programming-style

andrepd• 8 years ago

Just one short note of appreciation for this book: Chapter 24 (Quarentine) helped Haskell IO and monads "click" to me. Now I understand what they mean when they say, for example, that "`IO String` represents not a string but a computation that will return a String. You can store this computation (and chain them), but they won't produce a value until you run them".

Exercises in Programming Style

Related Stories