ITT 2016 - Kevlin Henney - Seven Ineffective Coding Habits of Many Programmers

good morning Canadian so one of my longer talk titles this is to keep you awake in the morning there are seven things I'm going to cover just so you can track them if oh just as a small point if you have children if you have not yet had children and plan to have children google their names before okay my parents gave me an Internet unique name before the internet was invented which I think was very clever but I will actually confess that for both of my son's I did google their names first and last together just to check and there was nobody there and last year my oldest son he went on Twitter and he said dad what shall I choose is my name cuz all his friends are like understand underscore John 73 or something stupid like that and I said try your full name and he said it's available and I said yes and that was 13 years in the making okay so just no good slow burn plans so are these relevant these are vaguely relevant I've got my names on a couple of books this is probably more relevant I edited a book 97 things every programmer should know because there's a diverse range of interest that we have in code and I want to focus very much today on details and style if you agree with everything that I say you probably weren't listening okay just to let you know if you agree with everything I say you're not listening to my talk but when you agree with everything I say text me email me you know Twitter oh yeah Kevin you were right okay so and just to let you know I just signed the contract for 97 things every Java programmer should know that interests you we're going to try and do another kind of crowdsource book so I have a number of interests outside programming including taking pictures of books I've got quite good at that I also write short fiction occasional isn't doesn't pay any money but I'm very interested in words and style very interesting words I run a Facebook page called work Friday which is about language linguistics and words and stuff like that but here I want to start off with the consideration of style so I'm going to pick on Doug Crockford book JavaScript the good parts which is you can tell from the shadow is a surprisingly slim book and but one of the greatest gems that Doug offers us is actually not to do with JavaScript it turns out style matters in programming for the same reason it matters in writing it makes for better reading so what is one of the problems one of the obstacles when you are reading code one of the first obstacles is noise there's so much going on so I want to talk about noisy code and when we talk about noisy code well let's understand what we mean there's a phrase that is often used signal-to-noise ratio a measure used in science and engineering that compares the level of a desired signal to the level of background noise and we use it figuratively in code as well we sometimes use it informally to refer the ratio of useful information to false or irrelevant data in a conversation or exchange when you look at source code how much of what you see is signal how much is noise how much is ritual just padding out the editor just filling up the screen and it doesn't really serve a role it doesn't actually serve to communicate and this is quite important because this visual sense that we have is is the main way of getting code into this and this it turns out is the bottleneck in software development your ability to comprehend and hold an idea in your head so let me just start off with something that was written a while ago Hamlet's soliloquy William Shakespeare to be or not to be that is the question and this is kind of fairly famous whether it is nobler in the mind to suffer the slings and arrows of outrageous fortune or to take arms against a sea of troubles and by opposing end them or if we translate this as Tom Burton did into modern business English continuing existence or cessation of existence those are the scenarios is it more empowering mentally to work towards an accommodation of the downsizings and negative outcomes of adversarial negative no circumstance or would it be a greater enhancement to the bottom line to move forwards to a challenge to etc there's a lot of code out there that looks like this there's certainly a lot of English out there that looks like this has it added any meaning has it had any depth has it added any communication this is just noise and we do a lot of this in code a couple of the other guidelines and observations are going to be related to this so here is a little piece of code it's not the biggest class you're ever going to see it's in c-sharp it's actually from a workshop that I run I work for myself I run workshops training courses and bits of consultancy and there's a example that I use when I talk about test-driven development very simple example a recently used list lots of people use stacks stacks of boring let's use recently use lists instead when you're recently opened files menu contains strings so you want a collection that hold strings and the most recent one goes to the head but they're also unique in other words when you reinsert or reopen a file that's already in there it doesn't get inserted twice it moves so what kind of logic is involved in a minimal implementation of this well this is one of the ones that a couple of my students a pair produced and they kind of looked to me and said we think this is a little bit long fortunately they're had tests so we could change it we think this is a little bit long yeah that's how long it needs to be and most of that is punctuation there's only actually five lines that does anything on the left hand side it's not the largest piece of code you will ever see as I said but it is far larger and holds far more logic than the version on the right it's not a case of whether or not this slide fits on a code I want you to imagine that you write a whole codebase in this style that's when it becomes important if this is your standard style suddenly instead of neat elegant one-liners you end up with code that has additional layers of logic that's additional noise it doesn't actually do anymore from the code on the right in fact it's actually slightly slower and yet we're very very good at doing this our other source of noise and code comments I'm going to pick on Oracle here but it's actually the same copyright message that son used to use look at all of that this basically tells you don't do bad things don't steal things we're not liable for anything that you do and please don't put this in a nuclear power station and then when we strip out all of the comments we are left with hello world that's it all of that for this and the one thing the one thing all of that I mean here we're told great things like display the string Wow but there's only all of the effort that went into that and you know what they missed something right here there should be a comma yeah okay if you're not sure why not there's a kind of a standard way of checking this one let's eat grandma let's eat grandma the first one has a comma and the second one doesn't good punctuation saves lives okay so the one thing they could have actually done they didn't do when I was learning see back in 1989 Rob Pike wrote this notes on see now III notes on programming a C and I it's interesting because I'm half of his guidelines is very specifically C related and some of them have changed with time but his guideline on comments is spot on a delicate matter requiring taste and judgment I tend to err on the side of eliminating comments for several reasons first if the code is clear and uses good type names and variable names it should explain itself yeah second comments aren't checked by the compiler this is an important consideration you have two audiences you have the compiler and you have other human beings my experience suggests that other human beings don't read comments and compilers don't read comments so who you writing them for okay comments are the last thing people will look at when everything has gone wrong it's like getting a new gadget the last thing you're going to do is actually look at the instructions of you're a geek you never look at the instructions it's like you should look at the instructions carefully no no no I can work this one out and when it's all gone wrong then you look at the instructions only to discover that they're wrong there's no guarantee they're right a misleading comment can be very confusing third the issue of typography comments clutter code they create noise but one of my favorite things in the Rob Pike article was this piece there is a famously bad comment style what I equals I plus 1 and 1/2 I and there are worse ways to do it what I love is that he says don't laugh now wait until you see it in real life I don't know I read this in 1990-1991 I laughed 5 years later I worked as a contractor in a bank in the city of London and somebody got me to look over their code and they had the second example I was very polite but I did laughs so I this caused me to make this observation when it comes to comments there's often this idea you know what the code might not be readable the code might not be readable why because the programmer didn't express themselves oh okay you should get the programmer to write comments then the same programmer that could not express themselves in the programming language is now going to be asked to express themselves again using a natural language I don't think it's necessarily going to work so that's the basic source of noise but there's something else I emphasized the visual sense seeing it turns out we see in a particular way so I want to talk about the one of the great holy subjects you are not supposed to talk about indentation yes I'm going to do it there is actually I've tried many different styles over the years it turns out I can't tell you what the one true style is but I can tell you what properties it should probably have based on what we see in code and how we use it I showed you this earlier on and I showed you this this is not how programmers would write it programmers are probably write it like this we have some very strange ideas about how to arrange code so here's a thought it's a nice big space there what's that big space doing let me put a line down it because this is how many programmers lay out their code they work on the logic it's just like that's fine I've got an HD screen you know it's big it's IMAX okay I'm good I've got two screens you know I like my code can run to the distance yeah see this even got a climate system the weather over at the end of that of that line is different to the weather at this end it has its own perspective there's any one problem that line there that's column eighty you might say I'll column eighty that's really kind of old and you know you should do that as terminals you know we've moved on beyond that yeah you want some really bad news how do people actually read column eighty is generous we should never be there turns out this is how people read it turns out if you look at webpages people don't use they don't fill up left to right they use columns look at newspapers look at any of the things that people have applied graphic design or layout principles to for centuries or more it turns out we're much better with that we don't respect that in code I'm not saying stick to eighty but if you hit the hundred if you hit three digits be very very very suspicious one of my clients we were going through their code and they actually mostly under eighty and then every now and then something went off the right-hand side and I said how far did these go off the right-hand side so we decided to suit up get our exploration gear get some water and set out and we set out on a mission and we found something in column 360 so their code is pretty much bip bip in fact this is a really interesting guideline I came across accidentally reviewing some code with a client I kept pointing out well one of the developers that kept saying you keep your columns your your your your lines are too long you are hitting the high row numbers and all the significant information is over here whereas people read from the beginning and we normally make judgments about what's over here based on what we see over here the problem is all the interesting stuff is over here this is very very self similar and he said oh it's fine I've got a big screen and all the rest of it but by the best bit was that we then did a code review with the rest of the team in a room using a projector and the projector because most projectors do had a lower resolution than his machine and you couldn't see it and we made this point those two lines are the same he said no no they're different around : hundred and fifty and we said well yeah but we can't see that yeah but it worked on my machine it's like this is a really interesting point it turns out that and I've encountered people who do things some really interesting ideas they will do code reviews by reviewing the code on arm tablets you know they might type them in using a decent workstation but then they'll get a coffee area and look through the code on tablets numbers use a different form to see what the code looks like for other people at other times and this very interesting thought here about what we might call clean design now this site daniel Higginbottom put this together clean out your mess a guide to visual design and he talks about clean design and he's we may be familiar with the idea of clean code but he's talking about clean visual design a clean design is one that supports visual thinking so people can meet their informational needs with a minimum of conscious effort this is an interesting thought because what we're saying here is that your code has a client that client is you or another developer so other developers are have requirements on your code they may never express them explicitly but they have implied requirements they are going to be clients of that code what do they want well they have why are they looking at your code are they looking at your code because it is amazing that they want to bask in its glory you'd like to think so but it probably turns out they want something from it they want information because that's that's one of the reasons this is often called an information science and so therefore there is this idea of information they need to know something they have informational needs how do we best serve those instead of than usual style Wars which are based on I like doing it like this so it's a very subjective or the company that provided the framework or the language does it like this it turns out they're not very good for years I've struggled with people saying yeah yeah but Microsoft do it that way and yeah but Apple do it that way and you know I've got kids when one of my kids says yeah yeah but one of my friends at school does it that way I have the same response and why should we be any different so here's the thought you convey information by the way your arranger designs elements in relation to each other this information is understood immediately if not consciously by people viewing your designs when you align things or separate things then people assume that things are aligned or and somehow there's somehow meaningfully related and if they're separated that they are somehow separated so we actually use a lot more subtle cues when we read through things we don't actually read what we think we read a lot a lot goes on in the in that's kind of background threads of your brain this is great if the visual relationships are obvious and accurate but if they're not your audience is going to get confused they'll have to examine your work carefully now sometimes people say well yes so they should because it is a work of brilliance it was hard to write so it should be hard to read this is not how we're going to go forward we want a better way of thinking about this so let me pick on a piece of code here so is this a sort of java method header this is probably one of the most common styles is probably accidental most of the time but I see this so often in in code where's the argument list argument list is one idea the argument list is all the way over here and all the way over there and if you're hitting hi column numbers when somebody says where's the argument list you know where are my parameters are well some are on that side of the stage and the rest are over there and yet we have an idea a single unified idea we call it an argument list it's a list yet somehow it manifests itself like rolling his cat in two different places in two different ways this is different this is this is visually confounding and I have actually had the conversation where something says oh yeah that - you know that that method takes two arguments no it doesn't it takes one oh no the other ones over there so this is obviously designed this this kind of style there's a reason the star comes about we'll have a look at it in a moment so I'm not going to tell you how to lay out your code I'm just going to say that there is a property that you want in other words my requirements are that when I deal with a list of things a an argument list when I deal with a list of parameters then it should look like a list it shouldn't look like it's been scattered to the four winds and you can do it horizontally you can do it vertically I don't care how you do it but it should look like a thing and so visually I read it in one go however there is also another common style that is not one that I'm going to go encourage this one it's lined up so there's a simple one thing but there's actually a reason that you shouldn't really do this oh there are reasons you might want to do it but let's understand this from a different point of view let's just do a very simple declaration with initialization it's very tempting to initialize like this there are problems with this by the way this is one of the reasons that our code over the last few years has been progressively moving further and further right because people do like to line up everything over here there's a problem though I'm going to suggest again I'll give you two suggestions there are more because I don't want to say I'm favoring one approach I want to say I'm favoring a property the property that I favor is that it is invariant and unchanging under refactoring when I rename something the first style is immediately breakable and immediately breaks this is one of the reasons we end up so it's actually worse than when we started whereas the other styles remain stable and they are unfazed and unchanged in terms of their visual correctness are their visual honesty if you like they are unchanged in the face of refactoring and particularly renaming being one of the most common ones now sometimes you are working in the language and an environment and with a common set of ideas across a team where actually the alignment is actually held if that is the case feel free to use it but most of the time in a lot of the languages that people are using there's only one person who has the editor that does that and everybody else uses something different in that case you're going to end up with this kind of mess that accumulates over time I share one guy tell me he said afterwards he said Oh Kevin I disagree with what you said I said well okay feel free you're wrong but feel free to disagree that is your right and he said yeah but I always I always make sure that it remains aligned and I said how do you do that he says I go around the whole code base checking that all the refactoring sites are still correct visually that's very heavy work for something that is so trivial and then I asked him what about your colleagues and the dark cloud appeared over him he said they don't do this I said there is the problem with the style it is not it does not work it does not scale across a team so if we're not going to do that and I'm going to start talking about indentation let's talk about other that spaces indentation so here's beats Java code that I mean I've changed the font to give you the real kind of sense of what's going on it disappears off the right-hand side it's got all these kinds of lines there's only about ten or eleven lines of code there visually it's very busy your eye has to do a lot of work why because there are effectively there's an alignment there there's an alignment there the first alignment is actually not the alignment that we want it's coincidental the second alignment may be meaningful the third alignment is kind of meaningful and then we've got these dominant indentation ones which are it's got six lines of attention and it's only got about ten or eleven lines of code that's very busy visually it's very busy and what else is the problem with this well if we just disappear and rearrange it like this if we followed this idea that we don't not going to push everything over to the right we discover that we have fewer lines of alignment but we have another problem and this is a problem that actually when put together with other styles you can see the problem what's the problem let's just get rid of the things and replace everything every identifier character with letter X and suddenly you realize you cannot tell where the parameter list stops and where the local variable declarations start this is one of the reasons that people are sometimes pushed into using this parameters all the way over on the right you cannot tell where they start you can say well yeah you can go back and look and see that there's noise over here but that's off at the right hand side serve the information needs of your reader do they want to read it like this not at all if it looks aligned it should be meaningful and that is not meaningful so there are a number of different ways of doing this again I don't want to favor one you can indent further or yeah it turns out that question that people have been asking for decades there is one true place to put your curly brackets and I can show you with this simple visual aspect I mean it's not that you can't read the other one it's just that actually this one is the most sustainable okay what else is going to cause noise and difficulty in our code just as an interesting point this is a very this is a very long and difficult book to read its comprises five or six sections the first section is written in English the remaining sections are written in Sigma calculus but it does make a very good doorstop and a good prompt on a Lego table because I want to talk about Lego naming what's the problem what is Lego naming well let's talk about language and linguistics for a moment let's talk about agglutination agglutination is a linguistics term it's a process in linguistic morphology derivation feel free to use that phrase back in the office to impress your colleagues I went to Istanbul tech talks I want to talk about linguistic morphology derivation of our identifier names in which complex words are formed by stringing together morphemes languages that use agglutination why they are called a glutinous of languages okay what examples well it turns out most of the Germanic family of languages is agglutinative and English still retains some of that this is technically the longest word in the English language although ironically it's completely made up of Greek and Latin and it was made up to be the longest word in English Norwegian is also Germanic language this actually refers to a traffic regulation so this is the longest word in Norwegian longest word in German refers to an EU directive that was withdrawn about three years ago so there's an interesting question as to whether or not it's still the longest word because it doesn't refer to a thing that exists anymore but of course we're here in Turkey Turkish is one of the classic agglutinative languages and the longest word officially listed for Turkish is this one at 74 characters admittedly the I'm not even going to try and pronounce it admittedly the author of this used it in a book with the purpose that it should be the longest word but we end up with this where do we end up with this in code are we see it all over the place this is a brilliant cartoon from last year beginning of last year the world seen by an object-oriented program privacy manager delegate entertainment provider singleton personal favorite multi but supporter entertain provider viewcontroller visitor monitor interface it's all here and yet and yet we know that the whole point of our is just name it what is it well that's a venetian blind that's a door that's a peephole these all have meaningful names in fact the only one that even remotely looks like it's Lego form is television remote control that's the only one that even retains any of that and we find this in code we find people going manager controller oh you've got to manage a controller you need a proxy for your manager control and you need a factory for that should it be abstract Oh an abstract factory proxy manager controller absolutely yeah and now you wonder why your code is disappearing off to the end into the day I see my code the meaningful identifier is over there we end up with what we what we can call homeopathic naming we dilute the meaning so much eventually it disappears it looks like it wants to mean something but it doesn't and it's a habit that starts it's a very it's not a habit that's new some people say oh yeah we're going to blame Java and we going to do this and you know they do that in the dotnet framework no not new at all it's one of my favorite books and small talk best practice patterns a lot of people don't use small talk or I've never heard a small talk but Kent Beck's book came out in 97 and it's a really good advice in here but he makes some points about naming people will be using the words you choose in their conversation for the next 20 years you want to be sure you do it right unfortunately many people get all formal just calling it what it is isn't enough and I found this with one of my clients this isn't a particularly long name but it's a very good example of where it starts with a very simple concept we start adding extra words and I remember talking to them so you've got a condition checker and there's a whole hierarchy of classes that are condition checkers and then what we do is we check the condition you see this with validators and as well as managers and all the rest of it and I said so what do these represent well these conditions and they listed off the conditions so this is actually a condition yeah and what you're trying to find out is whether or not is true yeah you mean that oh yeah these are good you get a feeling if you've seen the matrix there is a moment where Morpheus says to neo stop trying to hit me and hit me stop trying to dance around the name and say what it is and if you haven't seen the matrix that's your homework so the point here is it's not it's not just the really long names how do long games get long they start small and then we start adding clarifications and then we go over the hill we lose the clarity we end up with this noise and this is the observation Kent was making back in the mid nineties and we saw it before they have to tack on flowery computer science the impressive sounding and ultimately meaning this really like object thing component part manager entity or item somebody on Twitter the other day suggested a brilliant metric how much of a name is left when you remove all of these parts if there's nothing left that's definitely not a good sign so I'm going to pick on the dotnet framework I'm going to pick on some one of the very common habits as with many common habits and this is the point about this talk we have many habits and we are blind to them we don't even see that we're doing them because they're habits that's the whole point of a habit its automated its automated in your spine you the brain never gets involved your keyboard your keyboard just gets the entry from your spine through to your fingers this doesn't do any thinking but take a step back there has become a habit across a number of different languages and frameworks to put the word exception on the end of exceptions because that obviously makes it clearer because what what else would appear in a throw statement or a catch clause oh well you know it could be a string no it couldn't it's an exception by definition by its context in the same way that I don't label all of mine on exception classes non exception okay oh this is a class just in case you weren't sure and we see that if we strip off the names access violation exception okay these are actually good names that we take away the exception the names have a force all of their own they carry the meaning of the concept there's no ambiguity access violation I wonder if that's an exception or not the meaning is clear access violation bad in fact down there bad image format there is nothing good it's bad it's very very clear that this is not a thing that you want okay array type mismatch argument out of range I wonder what that could possibly mean it means an argument it's out of range oh yes it's there in the word now of course this doesn't apply across all of the standard dotnet types okay so let's have a look if we take these ones you might say well look if we take exception off then this doesn't mean much argument arithmetic context Marshall format none of these make any sense but that's not because they need exception that's because the name was banned to start with the clarification comes oh you mean invalid argument now I understand it's not just argument there's nothing wrong with a null reference it's the fact that you dereference it that's the problem name the problem name the situation don't kind of name things but oh it's something to do with arithmetic what is something to do with nulls now it's to do with dereferencing so we can actually be much more concrete omit needless words one the classics guidelines and english writings are Strunk and white summers pull away from this for a moment to another area which is under abstraction we're going to talk about words one of the common problems we have is under abstraction and I've kind of hinted at it with the problem of condition checker and things like that but the issue is to do with a lack of abstraction there's a technique that Phillipe Calvin first published about seven years ago now I've been a big fan of it take your code base take your code base strip out the comments strip out the string literals get rid of case sensitivity put it into a tag cloud generator and see what you can see and this is one of his original examples what we see first of all is the languages Java the next thing we see is because of the language like in words like important public is very dominant very visually dominant but beneath the language plumbing what do we see we see this is a system with strings in fact that's the dominant type this is what is known as a string Li type system and we also see lists and some integers that's kind of it so what is this system about I want you to imagine yourself at a party and some you're talking to somebody somebody you are potentially interested in and they ask you what you do I'm a software developer at this point they're looking for the door they're looking for their escape and but they hope maybe you're interesting they hope maybe you do some really cool game stuff or something really funky and they say so tell me about the systems that you work on and you say I work on systems of lists of strings and integers BAM they are out of that door is that the best we can say this system is obviously programmed in kind of object-oriented assembler we dumbed it all down you know the idea is in somebody's heads you know these everybody has a clear idea what the system does but somehow we've turned it all into strings and lists and integers and other fundamental types and collections by contrast this system is much richer I can't tell you exactly what it does but its domain is very very clear printing device paper product very very clear by comparison its domain is written all over it and that follows a guideline from 97 things every program should know that down north kind of highlights code in the language of the domain now sometimes people will will do this and say look I'm looking here I've got very clear identifiers portfolio IDs by a trader ID trader key portfolio yeah the only abbreviation in there is a real world abbreviation ID that's not even a programmer abbreviation and yet it's not entirely clear what the purpose of this condition is maybe we should put a comment in or maybe there's a different way of describing it we've got a missing abstraction and one of those very common things missing abstraction it's not the code it's not that the code does anything wrong it just doesn't communicate it doesn't fulfill the communication needs of its users on the other hand if trader can view portfolio does it's much clearer that's a permission check it's not just a lookup in a map of maps that's a technical expression of what is going on but that's not what it means what it means is whether we're trying to find out can this trader view this portfolio so one of the other areas that we have in terms of interest related to under abstraction oh yeah I don't like I don't like singleton but I don't I'm Anna jet this lined up there is a whisky called singleton it's much better for your code than the singleton pattern much better if you drink whisky when you have a sip of this you will pause for a moment and you'll feel the kind of the gentle fire of a good whisky and you'll pause again and you will think you know what maybe I won't put that big global variable in my code yeah that's enough but I managed to get the coke thing and son EXO cats Kevin Hanny singledom that's the only singleton I approve of what I'm really here to talk about is uninsulated state which is under abstraction as well by any other name let's go back to our friend the recent use list I get a lot of people implementing it in a number of ways they say oh we're going to have up just a property we'll publish the list the underlying implementation and then people can get their hands on it they can do what they want yeah the problem is that when you look at how it's used that's convenient at one level it saves somebody typing but it doesn't convey meaning and we end up with some problems in the resulting code the resulting code ends up looking a little bit okay we get our recent use list we add hello world we right now we start writing things out we end up with a train wreck we start going list dot items dot something when you start digging into the path name of an object you're missing something there's obviously something shorter people don't like long path names but they are also unstable when it comes to refactoring we also have the problem that we can bypass the encapsulation layer although we've used the private key word we've actually bypassed the encapsulation there because technically we haven't enforced the boundary the whole point of encapsulation is we put something in a capsule our capsule has a boundary has an inside and an outside and you protect the inside from the outside world by defining a clear model of usage if you like this is the user interface of an object the API of an object at the object level what is that interface like and it conveys meaning if you just simply offer people collections and things there's a loss of meaning there it also means that people can add do things like add duplicates or perform illegal operations like adding null we've said null should not be added they can now easily do that and they haven't had to use reflection or any any nasty trickery like that so these are very questionable I want to take you back briefly just for a moment to the 1980s so at least one person has seen this film has anybody seen The Lost Boys something we've seen the last boys this is this is your this is your optional homework it's quite 80s vampire movie before vampires got really big in movies and there are some defining characteristics of Hollywood vampires how do you protect yourself against a vampire those is a kind of question some people remember I think oh yeah you got a driver's got to drive a wooden stake through the vampire's heart that's quite up-close intimate and very very dangerous it's a high-risk strategy some people remember garlic that's a good one okay occasionally people will say silver bullets no no no your debt that's werewolves you've got to get your right supernatural creature yeah okay don't confuse don't confuse them all right but the one people invariably forget is don't invite a vampire in vampires cannot come into your home unless you invite them so this is the key idea you keep your code you keep the abstraction properly private that is the idea behind this you keep it so private that it means you forward operations your language may make forwarding easier or harder but the idea is that matters less than the coherent interface you offer another user because that's what they that's what they'll look to that's what they want meaning from so we can refactor we can change all kinds of things now this relates to we've got a couple of items which I'll wrap up this relates to another thing again it's the naming it's the encapsulation it's the rest of it it's the getters and setters here's an interesting thought people put get and set all over their code and they say well yeah then falling that it's a convention in English people might say okay is it what is the word let's have a look at the word let's have a look at the word get this is my copy of the Oxford English Dictionary it's it's all it's a it's on my laptop and I want to point out something here it's a very old word it's got four entries this is proportional to the size of the entry it turns out that the word get if you print out all of its definitions covers 35 pages when you use a word you want it to mean precisely one thing very clearly clearly get is not one of those get is one of the three words in the English language that has the most definitions it may not surprise you to know that set is one of the other ones the third one just for your interest is run we use run a lot as well and sometimes people say well look get and set they go together so nicely because they're like opposites well no they're not what's the opposite of set reset or unset these are the opposites so there's a there's a linguistic problem but also in some cases it encourages people to automatically without thinking either their fingers will do it or they've got their IDE set up to automatically every field ok automatically generator getter and a setter it's brilliant I love the fact that ideas and editors can be configured to automate the wrong thing so that you don't have to do it you can now do the wrong thing faster and not be involved and there's just a habit I've got a gal guys said it's like well no in a minute suddenly it's that's it it's much clearer you can own that you create a new object it has a state you don't need to change it if you want that you get a different object so here's a here's a thought just because you have a gear doesn't mean you should have a set and furthermore we can get rid of the words get and set because actually get something in English by default is a command it's an imperative and it has a side-effect I just want you to think for a moment you know if you get money from an ATM disappointingly there is a side effect on your account okay I'd love that it weren't if you get married there's a big side effect in the state of your life these are these are not just questions they they have very very profound implications okay so I'm going to finish on this question of unco he subtests what's our problem well the idea is everybody says you know okay TD d stands for test-driven development and this is a blurb taken from NAT Price and Steve Freeman's talk are your tests really driving your development it's a great title they did this talk they did the session XP day in London in 2007 and but they're the the words for their session are really good as well everybody knows TD d stands for test-driven development however people too often constructor with tests and development and don't consider what the word driven really implies for tests to really drive your development they must do more than just test the co performs its required functionality they must clearly express that required functionality to the reader and this is a really important idea that they must be clear specifications now we would take that let's go back to our friend the recently used list which has a constructor account property and index or an add method that's the minimal form the most common and tempting way of testing this is to have a one-for-one relationship I test the constructor I test the get I test the indexer I test the the problem here is that doesn't tell you the meaning and when you actually try and write these you will discover it's very difficult to test the constructor unless you also test the content it's very difficult to test ad unless you can test what's inside it in other words you use the object as a whole you don't use a method you use the whole object for a purpose for a scenario so this is how not to test it how do we test it well if we reorganize the code ever-so-slightly what we're going to end up with is a very different structure instead of thinking about it I've got a method and I've got a test that corresponds to each method what I'm going to find is my tests actually use other methods and they should be organized as scenarios and when we do that we end up with a very different kind of approach so I drop away the the end unit noise this is a recently used list spec I'm going to use the BDD terminology of spec and then we end up with a series of propositions statements that can be considered true or false when the test passes then that statement is true it's a true property of our code when it fails then it's a contradiction of what we wanted a new list is empty an empty list retains a single addition an empty list retains unique additions in stack order a non-empty list is unchanged when the head item is riad 'add an on enter list moves non head item to the head when it is reacted any less rejection additional items indexing past its end or negative indexing when we talk about things being like specifications we mean it it's not just some kind of like figurative indirection its direct is that's what the code should do that's what our test should do the idea is that each test case should be what pretty much as we'd expect a test case now that's the that's the intention that we use the language of test case but we don't think about it in terms of its true meaning so let me wrap up with just an observation from posit for a pose of five some level the style becomes a substance the little things matter in code for a very simple reason that's how you create large systems when people say don't worry about that is just details they forget what software is software is just details there really is nothing else if you can find something else I'd like to see it because that's what real software is it's lots of details put together by people to do a particular purpose it's just details there's no physical stuff there it is just the details and we create large things out of smaller things that are the same type of thing in a building we don't create big buildings out of little buildings with bricks we don't create big bricks out of smaller bricks but in software we create large software out of smaller pieces of software and we create those smaller pieces out of smaller pieces still it's Turtles all the way down there for the stuff you do down here when you repeat it ultimately becomes your architecture and with that I'm going to finish thank you very much you

Channel: Istanbul Tech Talks

Views: 545,215

Rating: 4.6562781 out of 5

Keywords: Istanbul, Tech, Talks, Development, Technology, writing better code, software architecture, software design, Kevlin Henney

Id: ZsHMHukIlJY

Length: 46min 28sec (2788 seconds)

Published: Wed Nov 16 2016