Whenever I hear strong opinions about coding styles I politely nod, agree and then launch into a series of questions designed to understand the background of wh

Whenever I hear strong opinions about coding styles I politely nod, agree and then launch into a series of questions designed to understand the background of whoever is articulating the opinion. Yes, coding style is shaped by personal preferences (where do YOU put your curly braces?), cultural affiliation (Microsofties and Hungarian notation) and a variety of other minor factors. However these are secondary to the main issue of how programmers build an underlying structure of the code. Structure is somewhat of an elusive concept, but use of object oriented programming (proper use) certainly leads to structural changes in the code. Along the same lines, use of recursion leads to a different structure than use of procedural style and so on. In short, structure for me is the underlying mathematical solution to the problem addressed by the code, regardless of the specific programming language. So going back to the issue of the coding style, I find that the background of the programmer is so important because it shapes their thinking about typical code structures. Someone with a background of writing payroll or other corporate financial systems (like many Thoughtworkers) falls naturally into a habit of thinking about code as a close approximation, if not a one-to-one representation of real worlds objects. Others with a systems background, who excel at using Nth order pointers to save 5Kb of RAM in a device driver care less about the real worlds objects than about differences in x86 parallel processing instruction semantics. However, if you put a systems dev guy and a corporate dev guy in a room together and make them talk to each other about programming they'll happily argue for days about how the corporate dev guy is a loser for not saving memory through pointer arithmetic and the systems guy is an idiot for not "getting it" about object oriented programming. So, to make the long story short, conversations about how <insert programming paradigm here> rocks/sucks are pretty much useless unless one first understands the target audience for the paradigm.