Giving code a good name - Kevlin Henney

okay good so you're the hardcore you stuck around to the end well done so what I'm going to talk about is naming and you're thinking how on earth can I talk about naming of variables methods and classes for 90 minutes my feeling is how could I not I've actually had to cut out a whole load of slides and topics so I don't actually be spending a lot of time on variables for example and field names and things like that so I'm going to get most you four types and methods things that are relevant things that irrelevant I need a new picture I've been using that one for years they got my name on the cover that's kind of relevant because it's software related also kind of relevant and also another picture I need to get a new one I don't just do software stuff I do I write a bit of short fiction I've been published in number places and why is this relevant well it turns out this books nothing to do with me but there's a quote from Doug Crockford that gives us the crossover it turns out style matters and programming for the same reason that it matters in writing it makes for better reading but I'm going to go a bit further there it's not just a quality of reading experience it actually has a profound impact and I noted in the blurb that I gave for this talk that the when you are communicating when you are writing code you are you've only got really three significant things that you use in your communication names spacing and punctuation programming languages are quite picky about punctuate punctuation so you can get a lot of latitude of that maybe the extra parentheses here and there but not a lot indentation there are enough conventions I mean there's certainly a lot to be said because what we do is we organize things visually we group things that we would like to be considered together and we separate things that we'd like to be considered apart I will say that programmers are pretty bad spacing they just think it's the default indentation setting on their idea there's an awful lot more to spacing than that but that's not this talk the most significant use of visual bandwidth is in the names and with something for casual with that no this this is one of my favorite programming books small talk best practice patterns by Kemp back it's just a way it's a very well-written book as well as having good advice so it hits on two levels its structure and its content and its style really bring out the core messages and he spends a bit of time talking about naming and on the areas he one of the points he mentions in addition to talking about intention revealing names he says you know people will be using the words you choose in their conversation for the next twenty years and he's focusing on classes and particular routes of class hierarchies yeah you want to be sure you do it right you are you're not just labeling pieces of code you're not just identifying using identifies you're actually creating a vocabulary and people will use that vocabulary outside the code that's how else are they going to talk about it so you're creating effectively a system of thinking it turns out problem is as he notes unfortunately many people get all formal just calling it what it is isn't enough so this is from a client of mine about a year ago public interface condition check a boolean check condition alright it's based on something from Atlanta mine dot dot obviously if there's nothing in the dot dot dot then we can you know use appropriate lambdas and stuff like that but there's idea this is fairly normal naming convention you know the use of the prefix check the idea that I've got to tell the reader about the interface it's a checker it's of this it's of that it's or whatever and I remember asking a question oh hang on what does you know I looked at some of these subclasses what was this is represented here what is this and I'm actually I came to the conclusion I say what you mean is that this is not a condition checker it's a condition and conditions are either true or false if you have cat so you just get this you get this okay because people are very very procedural in their approach yeah check this check that you're not checking is it or isn't it yeah there's a there's directness to the name that is missing you we add checker and we've added nothing except more letters okay now this is not a particularly large example you carry this to its logical extreme and you get enterprise code so as Kant notes they have to tack on a flowery computer science II impressive sounding but ultimately meaningless word like object thing component part manager entity or item and this is just a subset and let me just point out this was in 1997 18 years ago okay a lot of people think oh it's a recent trend now really heating Kent was relying on his experience in the 80s and 90s and I saw these trends as well it's a case of whenever you put object on the end of something it's like well of course it's an object that you know you don't have to explain to the reader that this is an object-oriented language or that we are dealing with objects and so so I will say that I don't see thing very often that doesn't sound technical enough okay if you want to impress your colleagues you up it to an entity or something like that but I've certainly seen object manager oh dear you see there's that there's a lot nice to advocate the manager pattern but that's because I understood how to apply it or I thought I did but now I've seen people miss apply it so much I'm very very very cautious it does have a role it's just not the one people use it for so the simple the punchy the easily remember will be far more effective in the long run than some long name that says it all but in such a way that no one wants to say it at all and there is an interesting pendulum swing that has occurred say 20 years ago I spent my time trying to convince people that they should use longer names because you know this is still at the tail end of the great vowel shortage of the 1970s and 80s where apparently there was a worldwide scarcity of such things and we see this all over the place is just like there is a name now rip out the vowels there's a shortage of that there we go but now people are over compensated the pendulum so I'm all the way to the other extremes and now you you know this is everything just gets elaborated and further and further and further and if you haven't told somebody it's an object perhaps you should tell them it's an object so I want to pick on this observation from dick Gabriel actually around the same time maybe published this around the same time that Kent's book was published they talked about the habitability of code habitability is an aspect of code that we often overlook it's a missing element of the arc of the architecture metaphor when we talk about architecture we know anything about structure and purpose and things like that but in any building there's another quality actually it is also true of code it's the characteristic of source code that enables programmers and people come into the code later in its life to understand its construction and intentions this is really important you know how do you understand somebody's intentions well you this is where this is where words come in this is how you are trying to communicate to somebody else you're trying to give them a mental model you're trying to place inside their head a way of working with the code and you're not going to do that with just a bit of spacing and a bit of punctuation this is where the words matter and often people overlook this because they're so busy focused on the task in hand which is very natural that's a human thing that they forget that actually what they're trying to do is create a model so what you're doing when you write code is trying to project a model into somebody else's head this is how we're working with this is how I want you to think about it these words indicate the architecture and the way to extend the architecture and modify the architecture that's what you're doing you may not have thought about like that but that is actually what's happening so you end up be able to change it confidently I comfortably and competently it also has this consequence of making a place livable like home which is what you want to feel in the codebase you can feel comfortable and if you end up you know I remember first on the first codebases ever worked on and in commercial code I remember the exciting discovery that there were a couple of main flags in the system that went by the imaginative imaginative names of flag one and flag two I mean you know that's one of those moments your heart sinks it's just like okay and what is it that flag one and flag to represent other than flag one was the first flag I thought off and flag two is the second you can tell that from the names yeah but turns out that that's kind of like trivia that's not helpful that doesn't really reveal intention that just reveals accidental sequencing so what we need is to improve the signal-to-noise ratio this is going to make our lives easier okay which will got signal noise ratio as a technical term level of a desired signal for the level background noise but we use it most often informally we talk about it as the ratio of useful information to false or irrelevant data in a conversation or exchange that's what you're doing in your code you've got a conversation or exchange that's what you're doing now sometimes I like to joke you know it's a Shakespeare one of the more famous pieces to be or not to be that is the question asked great stuff on the other hand if we write this in kind of like modern enterprise speak it looks like this continuing existence or cessation of existence those are the scenarios is it more empowering mentally to work towards a conversation of the downsizing as a negative we're seeing we've used longer words we've used more of them we must be but we must be really communicating at this point it turns out the communication is not a sort of question of quantity as a question of quality now I have more recently started to joke you know what actually programmers wouldn't write that they brought it like this but but my views on the indentation I will leave to another talk so I'm talking about words and when we talk about words a lot of people say oh no no Kevin you're wrong it's not just three things it's not just the three things you mentioned the spacing the punctuation and the names there's comments as well and how do we use comments do we use them wisely do we use them appropriately well I'm not going to pick on Oracle but I'm going to pick on Oracle but actually no I'm not going to pick on Oracle because this is representative of a surprisingly large class of comments there's a huge great banner there what is this banner for it's the hello world for heaven's sakes this app is Dwarfs the coat it's a one-liner and we have got this huge great you know please don't use this in a nuclear power station type of writes message up the front we get rid of that Wow but I do love the fact that it's a rather grandiose the hello world app come on it's not an app implants an application that simply prints hello world to standard output man that's actually a longer explanation than the code and this is Java and the codes already long so so then we get down to the code but there's still one comment display the string well that helped I'm glad they put that there you know my life is better as it but you know this is the interesting thing for all of this noise and it is quite impressive noise there's one thing they've got wrong and it's in the code for all of that they missed out a comma you put a comma there yeah they did all of this all of that and the one thing that actually relates to something real that somebody will observe is the missing comma if you're not sure about this one that there's a kind of like a fairly famous one that does the rounds a fairly famous mean you know there's yeah let's eat grandma let's eat grandma good punctuation saves lives okay there is a big difference between those two so one job one job and they screwed it up okay so let's try something else around time I was learning see mr. Rob Pike kind of one of the UNIX demigods wrote this rather good notes on programming cos written in 1989 and and I think I got to read it around 1991 I think and this is there's some good advice there there's some slightly dated advice and there's relatively timeless advice comments 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 second comments aren't checked by the compiler yes they not checked by by programmers either it turns out so there is no guarantee there right especially after the code is modified a misleading comment can be very confusing third the issue of typography comments clutter code they create a noise level but I think my favorite my favorite piece on comments in his newspaper was this one it's a famously bad comment star line because I just want to add one too I and there are worse ways to do it he's huge great banner statement add one two I don't laugh now wait until you see it in real life you know what I laughed five years later five years later I saw pretty I'm not exactly the same indentation but this example in a cutting a piece of code in a bank that bank went out of business six months later coincidence all right so you know here's the problem it is you know the gang back to the late 70s a very influential book the elements of programming style so I got recently accused my views on views on comments I'm not a no comments guy I just like really you need to cut back on them kind of guy and use them sparingly type of guy but somebody said ah you know it's just so trendy to not do comments and I said no really actually this is the book that I read that gave me my my views if a program is incorrect it matters little what the documentation says here documentation is referring to in code this is a good point if documentation does not agree with the code it is not worth much in fact I would say it is of negative value it's not simply not worth an awful lot actually you now have two stories the code is telling you the one that's the real one which is the code and then a different story which you might be seduced into believing but is actually is its basic journalism okay it's all lies okay three consequently Kobus largely document itself if it cannot rewrite the code rather than increase supplementary documentation good code needs fewer comments than bad code does if you take one bullet point away number three that is the one that you want it's a it's a profound insight okay rewrite it so I don't need the explanation what would I want to communicate to somebody so there's that there's the key idea comments should provide additional information I should never pair out the code mnemonic variable names and labels and so on should emphasize logical structure help make a program self documenting however I do put I do put a sort of a buffer or barrier of caution on that sometimes it's all too easy to say are the codes self-documenting which self made that judgment probably the self that wrote it you need another self to make the judgement yeah it's not really your judgment to make that it's self documenting sure to somebody else yeah that's that's that's sir this is where we get social with the code but there is this idea of there is a lack of guidance on this and so therefore comments lose comments are a little bit like gold in the sense that their value derives from their scarcity Gold's value derives from its scarcity is not worth as much per kilogram or something like iron iron is surprisingly common on this planet so therefore we don't charge as much for it as we do gold gold part of its value derives from a scarcity and you want that with your comments they should be gold and they should when you see a communist that's like this is worth pausing for and reading in other words it tells me something that is non obvious so there's also another thing that came out a tweet mine that seems to have got retweeted rather a lot common fallacy is to assume authors of incomprehensibly code will somehow be able to express themselves this early and clearly and calm it's sometimes people say oh yeah I like using comments to explain what I've done in the code okay so why did you not do that in the code and what manner of explanation you can offer I'm going to say writing clearly is hard it is non-trivial okay and I'd say that with my fiction author hat on and my technical author hat on and I think I kind of got the hang of writing maybe and I've been doing some form of writing since I know no primary school or something like that so a few decades and I think I might have got the hang of it but I'm not entirely sure ask me again in 10 years and I'll probably have a different view it's non-trivial to do this and if you're struggling to express yourself in one written format which actually gives you the appropriate bandwidth to explain yourself in then I don't rate your chances very highly elsewhere so this leads us into the code itself the names that are within the code that are significant to the compiler example I'm very fond of using comes originally from Philippe castle about six years ago the idea of using tag clouds I love this approach he did this it's from his original article he took a Java code base he stripped out all the comments stripped out all the string literals and in this particular case he made it case insensitive and just shoved it into tank cloud generator and this is what he got so you can say it's a Java system but we can't really say much about it I mean it's got strings it's got lists and it's got integers but that's kind of it and there's I'm gonna I'm going to put if I don't know what the system does actually there is one clue there but I don't know what the system does but I'm going to put a fair amount of money down that somebody did not there's no customer out there who said what we need is a system that handles strings that's what we need it's going to handle strings and we want to use lists and integers as well just to be sure but mostly it's about strings and so we have a string Li type system here now I'm sure it does lots of worthwhile stuff the problem here is that I would go back to this idea there's a conceptual model that you have in your head of how you're approaching something and between here and here sometimes it gets kind of translated down you end up with a sort of object-oriented assembler so the model gets broken down into constituent parts and lo the thing that runs runs and make sense at the level that it's been pitched it's kind of like we're missing out all those really great ideas that help you organize your thinking fully but also offered an alternative he showed a different system and here we see a much richer vocabulary and I can't tell you exactly what it does but you know printing device paper picture product the language of the domain is is very richly woven into the code these are class names these tell us what we're looking at okay they tell us something about the code in fact there's a minor point we can actually see the class keyword here is larger than in the previous code base there are more types it's probably about as much code but the code is organized into different units that have meaning and they are they are described described as such so that kind of takes us into this idea as Dan North wrote in code code in the language of the domain that the names matter but it's not just about abbreviations and it's not just about being explicit because if we look at this it portfolio IDs by trader ID don't get traded or get ID'd or contains key portfolio don't get ID if you look at that there is only one abbreviation in there and that's ID and that's not a programmer abbreviation that's a real-world abbreviation we use that abbreviation quite commonly in the real world and yet it's not clear what this does except it's a lookup of a map and maps and we might say well perhaps a comment would help no how can I rewrite the code to obviate the need for a comment ah well that changes it all of that code is still there but that notion of explanation has gone in to the code and has meaning can view trader can view portfolio oh right okay so this is actually to prevent insider dealing now if you want a comment you might refer to the appropriate legislation which is not obvious in the code but we're no longer telling people this is what this condition is trying to say it's trying to say that we're trying to check whether or not the trader can view the portfolio well in which case stop trying to hit me and hit me refactor just that's the name of the thing so refactoring is not simply a case of this class is too big it's a it's an act of explanation you know we if you've got an expression or a block of stuff and you want to put a comment over it well maybe maybe we've got it already got a construct for that in other words a method or a function or something appropriate so there is this idea that I put in the blurb for the session a good name is more than a label a good name should change the way the reader thinks okay so often when we discuss good naming conventions it's like we're discussing conventions for labeling that's not what it's about you're actually just you're trying to plant the seed of an idea trying to influence the reader very strongly towards a model-based view of how they want to reason about the code um as I said I talked about this one quite a lot somebody a couple of years after I first started talking graphically Quel'Thalas technique actually applied it to his own code as a gaming company it's a c-sharp code and this is really interesting we look at size of public huge its enormous and you know there's still kind of the kind of this string list equivalents game object and vector three but here the things that stand out for me not apart from the public void is enormous that tells me we've got a lot of methods that are in some way very very imperative we're saying do this do that do something also of extreme interest is bull false true else if you're looking for if you won't find it Wordle knocks out anything two letters and shorter this is very flag driven code very flag driven in fact we look over here we see case gets to be featured it's like we've got a very kind of switch case if else this flag set this flag do this which involves setting a flag and do that it seems there's a lot of state going on but we're not expressing it through polymorphism and delegates we're kind of expressing it through if else--if else--if since which cases so this is kind of something going on here so with this idea of losing you know sometimes we mechanize the names a little bit too much gregor hoeper has this piece that convenience is not an ility parser dot process nodes text comma false what's the false mean I understand what text is I've got a pretty good idea around parser and process nodes but false it's a mystery but it's a really strong habit that when we have two choices one way or the other that we say oh I know conveniently enough in the language there is a primitive concept that has only two values we'll use that one but from the outside you look at it sky I don't know what that means perhaps an enum or alternatively if it's actually two variants and in many cases this is what's going on it's two variations of behavior in actually when you look at it it's a review I did last week really interesting there were two things that were bully fide and you went in and you realize where the bull was used and it was if true then behave in this way else behave in a completely an utterly different way which is not even remotely related to this other case in other words that these two don't belong together this is actually what's called control coupling it's like I'm on the outside and I know there's two implementations and I say I want that one place well if there's two if there's two different purposes then then maybe we have a name for it process nodes with logging or process nodes with whatever it is that we're enabling so make it explicit of that level this is an opportunity for username if you ever come across I'm the most extreme case I came across was it was a method that had five boolean arguments on the inside it looked okay because they were all really well named if is enabled and stuff like that on the outside false false true true false what does that mean no idea this could be line noise so this gets us to the question that we've found a need for our names we found a need for communication but then we start overcompensating we kind of go into that kind of Shakespeare territory and we start and our most simple model for creating names is to glue bits together because this is one of the things that names are pretty good at to process in in linguistics called agglutination complex words are formed by stringing together morphemes each with a single grammatical or semantic meaning languages that use a glutton ation widely are called agglutinative languages in what can only be described as a fit of originality and so that English has this a bit it's all Germanic languages have this so English has it Dutch has it the Nordic languages have it but German has it in spades yeah there's it's you know you where most people would be satisfied with the sentence the German can only coin a word so here's some interesting examples this is technically the longest word in the English language without hitting Jois territory the great irony of this is that it's actually completely composed of Greek and Latin parts no there's no English parts there at all it's kind of pneumatic it's a Cipolla nary condition that you can get through breathing in dust or sand based things it's a completely made up word it was made up to be the longest word oh yeah your Norwegian you may have to encounter one of these I'm not even going to try to pronounce this I've had a go at a couple of times but it's one of those ones that if you're not a native speaker you've really got to take a run up and figure out where the jumps are you know figure out how I need to pause there and then move on there I'm absolutely but of course as I said Nordic language is pretty good on this nothing compared to German that is is all was the longest word in germ 6465 letters it really it relates to an EU directive which is no longer in force so there's a question is is this still a word because the thing it refers to no longer exists its abbreviation is 12 letters long if you happen to speak German I'd you know if you can fight you're funded German speaking is just get the right cadence and and gopher it's natural if you've been doing German for decades but for the rest of us who merely have menu level German it's quite a challenge sadly we take the sins of the code and we start using standard parts there's a whole load of things yeah yeah yeah okay yeah it's a service oh yeah okay we'll have the word service on me of course it's a service that's the whole point of software development you are you this piece of code provides a service for something else but you know it really is a service because it provides a service over the network in which case it's still a service and it's still software but what about this service within the process that's also a service well yes it's all services so the problem here is that um it doesn't really mean anything we've got all these extra bits and pieces that we add in to help so we'll tackle a couple of these by the way if you're ever struggling this is a webpage from Jeff foster method named accom you can just go and generate just refresh the screen give me another name give me another name abstract customer singles and fantastic copy paste code yeah yeah and even better you get to choose you get to choose your different naming styles I'll my first method names like Spring Framework style JDK style you know I think I can go through this and there's class name accom you can do the whole thing I'm still waiting for variable name accom and then my work here is complete because we can then create a service that automatically creates a program for you yeah I just I'll just hook it up it'll be like a glorified Twitter app and it's given right some enterprise application for you we'll take our variable names from their own method names from there and our class names from there brilliant okay just get a programmer involved every now and then to put an e for awhile in you know just for good measure obviously we needed a little bit better than this a good name should describe structure with intention that's its role don't don't tell me what I'm looking at that I can already tell then tell me stuff about the language tell me something about the intention why is this here I want to know what role it plays what part it plays as opposed to the affix heavy approach common to many naming conversions and current use you get the addition of prefixes and suffixes becomes homeopathic you end up diluting the meaning till there is nothing left this name is so descriptive it actually means nothing which leads us to the conclusion that good naming is part of good design so it's a slight it's a contrived example based on fairly typical enterprise you type code I could have gone further but I wanted to keep the font at the right size so I didn't have to do too much line wrapping there's all interfaces we got a bookend so imagine we've got some kind of simple catalog okay we're going to put books in the catalog and they've got ISBNs book entity yeah because there that tells us that it's an entity that's very helpful I wouldn't have known that otherwise I mean book as an obvious idea I could not have guessed it is a kind of thing that I'm interested in referring to and if where do I get my books from well you know you could create them or you could use a factory that's how you do things properly you're not allowed to use the new keyword now you need to write a whole class to wrap up new and how do we know our ISBN s-- international standard book numbers they have a rule of well formless how do I know that they're valid we need a validator yes we've got a repository and then we got a repository provider and you know exactly go further we can have a processor probably that's probably needed somewhere I've overlooked that because obviously you want to be able to add books oh maybe I need an ad book processor or maybe that's an ad book controller or maybe both why take one into the shower when you can have both and that's just the interfaces there's the implementations because obviously you know if you're going to have an abstract book entity implementing book entity then you need to tell people that it's abstract because the abstract keyword is not clear enough and nor is the compiler error that you get when you try to instantiate an abstract class no these are not strong enough clues we really really need to pour it on thick for the reader and so you get some outstanding there we go catalog repository provider import it's just but inside this there is a tiny little model that's trying to get out it's not very large we got books we've got is be ends if you want an ISBN it's not a string that has been validated and is being is a type of thing in that kind of we've got a technical word for thing I talked about thing earlier object that's it oh wow moment of enlightenment we could have a class for ISBNs and what would that class be responsible for well maybe we could move the validation somewhere else or it could validate so that all the ISBNs is in one place this is quite profound and we've got a catalog a nice bands just a value type so I'm just going to make it a final class so yeah fine and then I guess we need to start implementing things now I put that name in description of catalog implementation not because that's a good name it's in italics to say what what the role what the name should be tell me about the nature of the implementation and then perhaps that deals with other bits and pieces but the point here is at this level from the usage perspective I've actually got a very small model now it might actually go back a long way there might be other components here but we push them out backwards we don't splat them out sideways so that you know we give people a kind of full frontal assault yes we've made your life easier we're going to use dependency injection and we've made every interface totally visible at every single level and to make your life easier you're going to have to configure this using XML which bit of easier we struggling with it's a really simple concept an object is responsible for its own implementation if you need to pass something and find out what that thing is don't make it an artefact that is driven by these other technical decisions that kind of kick the encapsulation and intrinsic layering of your model out sideways so factor can and particularly I want to talk about the idea of the hierarchy naming or well we'll get to the hierarchy naming but one of the elements he focuses on one way to name classes is to give each a unique name indicative of its purpose that's kind of one of those obvious things but well yes that makes sense unique names give you the opportunity to convey a lot of information without creating names that are long and unwieldy in many cases we have a name that's good you know this is exactly the right thing to do if the names are in common use okay so go for it so simple example so let's try something else with books let's create a library because library models are very frequently used in workshops in fact I still use them in training workshops I remember working a colleague a few years ago he said Oh Carolyn you should stop using library examples because I remember doing library examples in the university in the 1980s and you know I've seen books that use the library example going back to the 1970s stuff like that he says you know Kevin you need to really get with it you know you've got to have a video rental store well I claimed I won okay libraries are stable by comparison with video rental stores so what are we got let's just focus on one aspect here let's focus on simple relationship between a member and a book copy that relationship is called a loan okay I've chosen already chosen simplest names possible sometimes when I run this I've ended up with loan record no lo that's that's pretty straightforward English I have clarified book though because there is a distinction there's an ambiguity in the terminology of book it turns out you you need to add enough to disambiguate things so for example when I talk about book I go to Amazon I say I'm going to buy a book okay I'm just Lu you know Sammy says how are you doing I'm just looking at books well you're not really looking at books you're looking at book titles since what my publishers call them book titles they're kind of the product as it were it's like the car model the book copy is the thing that you actually comes through the post in theory at this point in time I am helping to write a book but I'm not writing a book copy Kevin could you give me a copy of your oh yeah hang on let me just write it again I'm writing the manuscript from which the book copy is actually ultimately produced under the aegis of the book title the other word the word book turns out to have different meanings depending on the context and in natural human language we've kind of were quite happy to play with this and go with this but code needs to be a little crisper so you don't borrow you know you're not borrowing a book title so to speak you're borrowing a book copy an actual physical thing okay now we may say well you know what I feel a need to abstract a little bit it's very flat at this level perhaps you know to create a more stable and partition model I'm going to factor out I'm going to introduce interfaces of there's a couple of things that I'm not doing strict UML here it's mostly correcting ul and so I'm going to have the actual member an actual book copy classes here and loan is not going to see the concrete classes I know it's going to just define its relationship with respect to interfaces but what shall we call those interfaces I I i member i book coffee there yeah problem solved yeah it's quite obvious that there's a relationship between these and yeah we've solved the problem of actually having to think this is a really lazy naming convention you see it everywhere the problem is that many of the examples that we see this in other people learn from example not explicitly implicitly if you're exposed to certain kinds of coding habits and certain kinds of coding vengeance don't be surprised when those turn up in your code because you know if you've got kids you'll notice your speech patterns turning up in your kids okay so it's natural we are we're good at copying right we don't even know we're doing it but if you pause from home and sing Hangul I've not really said anything useful here I've not actually added anything I've just kind of skirted around the issue because if you look at it what we've ended up doing is I mean we've certainly aligned to these things it's like okay there's a membership I mean there's a book coffee hierarchy but we've aligned it like that we may even package it like that but it turns out that's completely the wrong way of looking at it the way you want to look at it is like this it's about the lone relationships it's not a it's very difficult to understand how a class hierarchy should be named unless you understand how it's used so this is one of the things I always despair of and why certain convey actions for class hierarchy design not just the naming I've never made sense to me because they normally have this drawing of a class hierarchy and there's no code using it how can I tell what the good names are and what the good methods should be if nobody shows me how it's been used and it turns out that object orientation curiously enough is not really about the object it's about the interactions it's about the relationship so it doesn't really make sense to talk about that as being I remember I book it because the point of view of a lone we want to focus on the roles you have to take a very object centric view now a technique that I learned many years ago and I found the source of this a couple of years ago is imagine yourself inside an object instead of the privileged perspective you get as a developer by privileged you have a privileged perspective you can see inside classes you can kind of move through the whole code base as if you were moving through the plans of a building you can see it from above but when you actually experience a building you have to walk through it room at a time it looks in this building looks very different when you look at the plan view than the experience of walking through it so you need to do that for your code put yourself in an object what can you see why is that object over there why do you have a relationship to that object why do you have a reference to it what role what does it mean to you is its membership important knows the role a part in a play or film while not quite a person or things function in the particular situation that's meaningful a function part or expected behavior performed in a particular operational process so tell let me focus on the role now when we take a role based perspective this becomes a lot easier allô in other words it's not about the hierarchies alone is nothing to do with class hierarchies alone is an arrangement between a borrower and a lone item sadly English doesn't have a very good term for the right-hand side so we have to put the item in there occasionally people sort of put loanable but that's not that much better and borrow herbal is actually quite difficult to say so lone item is a reasonable compromise but in other words what we've just done is we have encapsulated the essence and correctly aligned it's not to do not vertically aligned it's horizontally aligned alone is a relationship between a borrower and a loan item when you're capturing the essence of something we have it there is a word for that it's called abstraction abstraction is that you are removing all the stuff that doesn't matter and what is interesting is that if we just left borrow as I member if we just left borrow as I member the chances are it would have a whole load of methods that make no sense from the loan perspective it would probably have it would have names that relate to being a member such as the membership number such as the name and the address and other things but that's not important if I'm going to be a borrower then I need to be able to attach a loan and detach a loan if I'm going to be a loan item the book title is not important nor is the ISBN number but whether or not I'm available that sends out to be supremely important so what is interesting here is that you actually end up with a narrow interface because borrower doesn't need these name these other features so the name I member actually causes you to put more code in it increases the coupling of your code you end up with a wider method interface the borrower interface is intrinsically narrower now of course if you are feeling a little uncomfortable in going my whole life really I'm down not comfortable with the sort of this the idea there and you want to put interface back in feel free but you want to put the I there but I my instincts you know I don't worry about it quite as much but I generally when people have a choice on this one I I do try to influence them away from putting the I keyword in because it turns out that interface even not when it's not presented in shocking yellow on shocking pink is normally quite visible within your code how on earth will I know that this thing is an interface could it be the interface keyword in front of it I don't know so I'm just going to give that as a consideration feel free to put the eye back in and if you're having an eye base convention feel free to stick with it but I would urge you well if you're using it whenever you are making a name choice consider stripping out the eyes and making sure your names are unique you know identify the roles and then put the I thing back in I have heard there's a sort of a very anthropomorphic naming convention which hasn't really caught on I think it's kind of interesting as an experiment I personally don't go for it but I do invite people to experiment with it that kind of emphasizes the role thing and takes advantage if you're using English names in your code then you can take advantage of yeah you know I am borrowing or I am loanable or you know stuff like that you actually use the I constructively in the name I think it's a little cute but you know your mileage may vary feel free to experiment so let's try another example this is a workshop example actually all the way through the code that I use used with one group let me just sort of distill the essence of it you've got a parser so I'll jump into part of the design there is a parser that takes some input and you Jason or something like that there is a builder you're going to tell the Builder look I'm building a parse tree so you tell the parser sends events to the Builder the Builder builds a tree and you get the resulting tree from that brilliant now I feel ok I need to decouple this a little bit so maybe I'm going to do this now we've been forewarned about the I prefix problem so we've got a solution oh yes there you go that's so much better I'm going to put in pull on the end so I'm going to keep you keep the good name for the interface and then put in pull it's just like ah this is kind of the same problem but the other way up because we're still emphasizing builder builder imple and that relationship doesn't really tell us what's going on let's try this one again let's try a horizontal view from the point of view of the parser is it a builder well no I'm sending events to it look I've just encountered the beginning of a sequence look I've just encountered an integer literal look I've just encountered a string literal it's an event handler so perhaps part of this neural paths or event handler or something like that but the idea is that look at it from the parsers point of view that interface as a friend of mine used to call it an outer face this is kind of two-part contract you want to use me you call these methods but you have to look like this and I will call back on you so what is it from the pastor's point of view it's nothing to do with building in fact curiously enough from the pastor's point of view the past tree is actually irrelevant because we've just outsourced the problem we've got a parser we send parser events to the parser list now we don't know what it does with it which is exactly what a good decoupled design should look like this piece of code should have no idea nor any care of what another piece of code does it should be quite selfish about things I'm just sending you events what you do with them is entirely up to you you could mock them you can build parse trees your problem not mine and when we look at it we realize why is the tree still dependent why is that being referred to in the interface you know there may be something like a get resulting tree type method there you go that's because it's nothing to do with it the fact that we're using a bit we're plugging in a builder to an event sequence fact that we're plugging in the Builder in order to produce tree as none of positive the parses concerned why should it have to care it I care about this you just plug it in let it go so here's the interesting thing is once you start shifting the names it turns out that you start shifting the design and the design shifts into the direction of narrower interfaces with less coupling names actually have an architectural impact in the long term now sometimes when you're organizing a hierarchy you can't get all of this right so maybe you need to use a qualified subclass name you can communicate how the new class new subclass is the same by naming some superclass it need not be the immediate superclass if some distant ancestor communicates more clearly you can communicate how the new class is different by finding a word that accurately highlights the reason the new class isn't just the superclass so this gives us a kind of compound name but we have compound name with motivation so we imagine we've got something like this got connection from which we're getting some kind of data where'd you get your connections from you get them from a connection factory of course I don't know maybe we should use a shop metaphor you know maybe because that's where you really get things from you know people don't go to the source these days you get them from a shop however connection factory produces connections which are implemented using connection input mmm let's try this one again let's be more specific perhaps what is that you have to ask yourself what is the defining characteristic it's very very rare that you ever want a factory called factory in other words a factory is a role that you attach in most cases to an existing class so for example in Java there is a collection interface there is a collection hierarchy if I want to iterate over a collection then I asked for an iterator and it produces an iterator now this is really obvious you know I go up to something like a linked list and I say hey give me an iterator and it gives me an iterator and yeah I don't use the word Factory anywhere a collection is an iterator Factory it doesn't matter that it doesn't have it in its name it is an iterator factory the factory always has been and always will be Factory is a role that it plays it's not a naming convention it's a role that it plays so what is the thing that you really want to communicate it's not it's a factory perhaps we've got a connection pool perhaps there's something else but I'm going to focus on it's a connection pool that's what makes it interesting it's not a connection factory that happens to pull it's a connection pool that's the most important thing right we've got a connection that's our interface we've got a good name for the interface we keep that and therefore by definition the implementation that we're interested in is a pooled connection that's what makes this connection interesting so we use this qualified approach so we've got this idea either using distinct names and role-based naming or a qualified approach and these two pretty much give you you know most class and interface names you ever going to need let's let's go into the connection pool how might we write this our habits go all the way to argument names and and method names and exception names connection create connection it's very easy you don't even have to think about it your your fingers just reach for create connection provider provider that's a very common naming convention in other words you just name the variable after the class it's kind of easy especially if you use a case convention that allows you to do that it's kind of like yeah it's easy but it's not always the best thing and when you're when you're looking at it from the interface on the view perhaps that you can be more expressive and then throws connection failure exception what's really going on here this is a very although there's nothing technically wrong with this description it slacking slacking communication I'm just taking Lego parts of names down from the shelf and putting them together and saying here I've got some code let's try this ah right connect to that's what you're trying to do you creating a connect just as I don't say I don't go to a collection and say create me an iterator dear collection I say iterator that's just straightforward in that case we can actually even choose some other names wither with hindsight but here connect to it's very intentional this connect of that it's a provider provider of what of updates you can do what you want with those argument names because they're not they don't have any role outside they're just living documentation and it throws connection failure oh my god I haven't put the word exception on the end and occasionally this gets people kind of upset or hot under the collar and I mentioned this in a session here last year and had a very extended discussion out site which is probably and that might have been prefixed but I did this back in February today's defines writing exceptions whose names don't end with exception result names shorter and more exception like sky hasn't fallen a revelation let's look at this such a habit you don't even know you're doing it it's such a habit I didn't know I was doing I found myself writing this one day and thought why am I putting exception on the end of course you can't change it for things that are already there and given in third-party libraries but there's no reason you should continue this maybe requires it and if they do they shouldn't let's look I said I went to the dotnet libraries and dug dug this out here are some things that you can find in the system namespace access violation exception argument and arrange exception array type mismatch exception bad image format exception cannot upload app domain exception entry point not found exception index out of range exception invalid operation is to overflow exception let's just try taking the exception off the end ah these are actually quite good names there's no mystery as to what their role is in the code I mean you know they inherit from exception they're used in throw statements and catch clauses what could they possibly be I have no idea it's a mystery to me especially with names like access violation I have no idea whether that's a bad thing what the word violation argument out-of-range that's obviously a positive thing no it isn't a Rea type mismatch the word mismatches already tells you this is not good bad image format you know you've got me stumped there is that a good thing or a bad thing no bad cannot unload abdomen there is nothing about that that says this is good okay entry point not found oh yeah you are looking at sort of despondency index out of range invalid operation all of these things when you look at them you sell you guys actually these are quite good names but we've we've kind of taken away the goodness of the name by saying it's an exception about this well of course it's an actually it's not an exception about an axis violation it is an access violation that is being signaled people look at the forget the purpose of exception handling the role there is to signal something and so therefore describe the signal tell me what what is going on and there's no need to put the extra word especially such a long word it turns out these are already pretty good now you might say ok look you've cherry-picks you've gone through the system namespace and you cherry-pick Kevin because here's a bunch of other ones ok argument section has magic exception context Marshal exception yeah yeah see what happens when I take the exception suffix off see argument arithmetic context marshall field's access format null reference object disposed rank type access you see these names they need exception no they don't they were bad names to start with putting exception was a panic button response these names suck they don't tell you what's going on argument exception arithmetic exception a clues something to do but you know null reference what could that possibly mean I mean we've we've got so used to it that we forget that this is actually meaningless there there's nothing wrong with having a null reference if I have a reference it can be null that's the whole point look at the language definition it's perfectly acceptable you can't have an exception that says you've got a null reference that's really not very kind so in other words the problem is that these are actually bad names putting exception is just you know kind like a plaster on it that's it it doesn't really help let's try that again my god what look at that invalid argument suddenly I've communicated what's really the problem it's an invalid something to do with arguments being exceptional it's to do with the fact it's invalid ah and that's an invalid arithmetic operation and it's a failed context Marshall an invalid field access and an invalid format and the problem with null was not that you had one but that you D referenced it and so on and so on these are names are describing the situation it's how you would name an event tell me the event that's going on it's a bad event because it's an exception but to use an event based name and feel free to be descriptive you know we've all got dictionaries are easy to find so as Strunk and white and the original Elements of Style said yeah omit needless words you know needle is extra noise you the reader already has an awful lot to look at don't don't label them with stuff particularly it turns out that when you put in certain things and they there's repeating patterns human beings have a thing that they do with repeating patterns they tune them out it's there's very good evolutionary reasons for this but you tune them out once you see lots of repeating parts you stop seeing them after a while it's them there's a recent study actually about warning dialog boxes it turns out that after the FIR you know if you keep exposing people to what they actually tuned out they do automatically they don't even know they're doing it like end-user license agreements yeah it's just that it's just like you don't even know yeah except you know as a box or I'm try use the service why is it not oh because there's a little red thing saying you haven't ticked this what are you going to do read the end-user License Agreement a course start come on click done and this is the problem we tuned the stuff at we don't even know we're doing it so when you start filling the names with noise and parts that we chew now they like they lose their significance that's an exception that's an object that's a manager if you start making all the names like this before long you kind of think hang olds are looking at again and then this is the problem it's become so familiar it's lost its original power oh yes get so I quite like kind of language things so I have a copy of the Oxford English Dictionary on my laptop because the physical version I think they've actually stopped selling it and gave me an update because it's so ridiculously forest destroying but you know it's got you know the better part of a million words and it's just to clarify as unless you are a language geek you definitely don't want to get the OED because if you're looking for a dictionary that will help you help you with usage it won't but by god it will give you the history of it because this is cognate get the word gets cognate with the old norse and middle period swedish and this is really useful stuff yeah i mean this is going to affect your day to day usage of it you get the complete history and the first entry is never the most common usage which is a usage based dictionary it's typically the earliest historical so you'll get the current stuff is always at the end so this is not a dictionary of usage but if you are into your language junkie then I strongly recommend this it's fantastic yeah you've got the English language going back to the first Malaya's it's great and now the thing I would like to draw your attention to is on the left hand side you see get and there are forehead entries forget and on the right I would like you to draw your attention to the size of the scroll bar yes it is proportionate it turns out they get is one of the two words with the longest entry in the OED and the second one is set during attention to that and it's nice to know about the relationship to old Frisian which I think is essential in our day to day usage of the term set now I'm picking on these guys because they they get used together they have there's this accident that happened in English there is this coincidence get and set are almost saying they sound similar they have euphony they rhyme get set they're spelt kind of two thirds the same fantastic I can I don't have to worry about conserving vowels you know there's only one in there and it's the same one that's fantastic getting set and they they're the same length now for people who work with mono spaced fonts namely programmers there are a few freakish programmers who do not use more space fonts we don't talk about them it lines up really nicely so this is alignment alignment matters in code readability this nice they line up get and set they rhyme and they're kind of opposites except they're not see the opposite set is reset or unset the opposite of set is not get get is just a query and there is a problem actually there is an ambiguity when we talk about the word get and we use the word get there is is get a does it have a side effect or not or is it a pure query that's kind of interesting because it's not entirely clear because sometimes it is and you actually go through if you go through a series of libraries what you'll find is that in most cases get indicates a query but in some cases it actually indicates something with a side-effect if we actually look at everyday usage of the term then we discover that actually get in English me means has a side effect let me pick a couple of examples well I have a wedding ring do you know what that means it means that once upon a time I was not married and then I was and what happened I got married ah when you get married there is a side effect there is a fundamental state change in your life no it's not merely a query it's actually quite profound if I go to the cash machine and I get money from my bank account disappointingly my bank balance goes down I would love that to be a fuel query get means has huge great side effect that's what it means so the problem is we kind of miss using the language as well where you're just adding noise so if we look you know God given we talk about money let's imagine you know most money most monetary systems these days break down into a very simple model you know you got a currency you've got units and you've got hundreds get units get hundreds get currency and there is a problem that we follow through without really thinking about it because the associations it feels very very natural I got together I put in a setter you don't even think about it set unit sounds well it's not how we should do this now I did a whole talk on more functional thinking and the use of immutability so the first thing I'm going to do is like no it's a proper value class its shareable it's immutable fine done let's get rid of the setters so we can get rid of that I'm not saying you should never have a thing called set I'm just saying that if we reach for that as our default in other words if we do that without thinking then often it ends up all over the place it loses it's potent sometimes I do want to use a word set and I really want to mean it in some way and then we get get units get hundreds get currency now is there anything here that is you know am I getting any better than if I do that well no because these are just queries I've also got a slight problem this goes back a long long way is that I am concerned that this reliance on this kind of imperative language is actually stopping people thinking in a non imperative way because get is a very imperative name it's telling the Machine that I'm going to go somewhere to a fee and get a value just ask for the value what are the units of this what are the hundreds what's the currency it turns out that it's it doesn't really break people's brains when you do this so this is and this we can't blame we can't blame a dotnet or or Java or you know anybody for this because I found an article that I wrote 20 years ago where I was already complaining of this I'd seen it in a lot of carries just like ours is lazy naming just got a name directly so kind of to sort of bring things to a kind of considered clothes well quite close but I just want to on the get thing so I consider some of these names and what they tell us and the embarrassment get length you know I used to get a lot of spam that suggested that not good length get position index it seems very explicit notice that when these names get long it's never because people are trying to obscure something in point is that people don't set out when you're writing your code you're just following through and the thoughts come to you and they flow out of your fingers and based on habits and things that you see around you this is very very natural but it's also one of the reasons that we don't write code in ink because there is this idea of like oh actually that's not such a good name now I think about it you know they might just proud right yeah index oh yes yeah we said so there's that now obviously there are other bits and pieces where you can kind of say ah right okay look I've got this object has a list and now I'm going to ask it for its internal list and the replace correct name for this is nothing because you don't want to do that you're violating encapsulation okay this is the problem what we start getting into this are getting the feel and getting the field i'm getting the field is like well well wait a minute that's the private collection you're going to give somebody the private collection that you have you have got custody over that you have curated carefully so that nonsense doesn't get into it and you're just going to give them a reference to the underlying collection so they can put anything they want in it and when you decide you know what that wasn't such a smart idea what I meant to use was some kind of dictionary or map type Oh now we've hard-coded it oops perhaps I shouldn't have given away the private sections coupling through collections is a very very common problem it's also an indicator of anemic domain models and your codes not really doing anything it's probably sitting in a controller or processor over there but actually we're just it's just shuffling collections of things around it's just like wait a minute let's give it a bit of life what does it actually do get instance or we got a singleton we know what to do with Singleton's there we go done okay so names very very useful when you start thinking about them you should always go back to a name your first draft is never going to be enough this is one of the most important things that we learn in coding but actually it's gain I'm going to go back to writing it's one of the most important things you learn in writing and those there are things Elmore James that said you know writing is rewriting that is the thing that you do it's not merely just the first moment it's that's your first draft you go back and you look at that and you go what I'm really trying to say is and you express that now I made a throwaway comment earlier on that naming has architectural implications that's not always obvious I mean we started seeing how actually will influence the thinking of your design it'll influence the number of things that you put in there and what we find in lost every single case is that when you get your names right interfaces get narrower they get sharper they get more precise whereas sometimes it feels like interfaces to objects are quite wide it's kind of like a sour first thought we kind of you know sort of a brainstorming allowed into the into the method interface and then you start thinking in sharp me down you know what that doesn't really belong then you move it out and you get a sharper idea you sharpen it and it's precise it and the consequence is that it reduces the coupling and often reduces the code the amount of code so it's rather nice book by Stewart Brand how buildings learn talks about how buildings actually get changed over time how he effectively evolved in practice and he has an illustration here based on and this illustration it's used in the big ball of mud paper by Joe Yoder and Brian foot and the idea here is I'm not going to try and pitch you a six-layer architecture where every layer begins with s and it must look like a building no it's based on an analysis originally from the architect Frank Duffy who identified a four layer model for kind of functional buildings office buildings as opposed to residential buildings and he noticed that there are these layers of change there's the site on which a building is founded this is the most stable and then you have the load-bearing structure this is the next most stable thing I was is less likely to change you don't normally change the site of a building I'm going to change the site of a building means either its experienced an earthquake or somebody has bought the building up brick for brick for historical significance and relocated it somewhere in the middle of Arizona so the point there is the site is profoundly stable this load-bearing structure is also very stable but perhaps less so maybe open to renovation and change and upgrades then you have the exterior skin the facade of the building which are office buildings is something like twenty to forty year cycle before it gets revisited then you have the services which are on a five to fifteen year cycle the lighting the cabling the heating the aircon all this kind of stuff these these get these shift so you want to know and then you have an actual space plan and the stuff within it like the chairs these are highly volatile you know those chairs were there earlier but they got now ok these can be changing on the level of minutes and hours and as opposed to decades or centuries so there's this idea you want to organize a building in sympathy with these changes don't make it don't put your fast changing services don't embed those in the slow changing skin for example so there is this idea of creating an architecture and sympathy now we have a similar thing although perhaps less visual in code there are layers there are things that change and are more stable than others there's the kind of like the soft center of the egg there is the the private stuff within a method versus the public exterior of something which perhaps moves a little more slowly and certainly when it hits public api's it moves more slowly and the problem is when we approach a programming language when we approach code and you're looking it in the editor you know what that code that's fast changing looks exactly the same as the code that's incredibly stable it doesn't list not differentiate it as clearly as these physical things so when you're just typing interface there it doesn't look like this is an interface we need to take a little more care over because it's exactly the same syntax and parts of the language and why does this make a difference well this is what makes a difference I was always uncomfortable with Suns package model the Java package model when Java so first came out I remember reading about it I thought it's pretty cool there's a lot of really good ideas in this language in terms of simplifications and so on but the package model bugged me I mean it was clearly sitting there being utterly buzzword compliant riding the wave of all everybody's getting into the Internet yeah you know CGI script for the whim that was the internet back then but everybody was piggybacking on this and so therefore it seemed natural as a way of identifying a company why don't we use the internet name why Cole idea and it'll also cause Java programs to use ridiculously deep directory structures but I remember feeling uncomfortable the idea at the time but I was uncomfortable with it for a couple of reasons but later realized actually the reason is architecture sun no longer exists but as a whole bunch of packages called package to conduct sun and how easily can you change this it's it's fixed so it also tells us that our names we need to take some care with them because you know you might be certainly not programming Java it's not my problem okay just go and look for your company name or your product name in your codebase this happens a lot people use namespaces and other structures that indicate the product name as it was at one point and you know what who controls the product name it's not the people that code it so therefore don't choose a name that is outside the realm of your control that has nothing to do with you the logic of your domain how companies name themselves how they merge and emerge is entirely up three it has nothing to do with the domain model the code or anything like that or anything that you can influence directly unless you happen to own a start-up there is nothing there you can change I always kind of Muse that if you know if we if we look at the the companies are around in 1995 in 1996 how many of them are still around with the same name so one of my clients is Siemens back then it was still Siemens Nixdorf so you have all these little bits and pieces it turns out the company name is one of the first things to go it changes companies merge and D merge in fact around that time I was working for a company and I ended up working with this guy who state who joined while I was there and his CV had an impressive list of companies that he worked for in the last ten years for companies actually he had exactly the same desk okay the company had been brought in different points been sold off been rebranded but apparently he worked for four different companies yeah don't name something that is stable which is something like the partitioning of your code don't name something that is inherently more stable than the world around it on something that is highly volatile now does that tell you what to name it no it just tells you what not to name it so I'm not being totally helpful there but it is identifying is an early warning signal there is a certain irony that josh bloch who used to work for sun made this observation public API is like diamonds are forever once you publish them you're damned you cannot change these things it's so there is a sense in which there are things that look like good ideas and we may adopt them and we often do and then you look back at in-game yarns and so smart so as mine and Fowler notice there's no problem changing a method name if you have access to all the code calls it even if the method is public as long as you can reach and change all the calls you can rename the method for the problem only if the interface is being used by code you cannot find and change so therefore be really careful with these things it turns out your refactoring tools will not help you when it comes to dealing with code that is you've already published outside your boundary of control and trust your initial team or initial organization and he uses a different term since when this happens I say that an interface becomes a published interface and ask kind of different role but it doesn't have a syntax which leaves us with Ralph Johnson's rather nice observation architecture is the decisions you wish you could get right early in a project but that you are not necessarily more likely to get right than any other and this applies to names in many cases but not in all cases there is this idea of identify where the name is and sometimes there is this kind of feedback between the names and the structures so I'll leave you with some three basic pieces of advice from a book on writing the observation deck by Naomi Apple choose the right name get specific eliminate words thank you very much have a couple of minutes for questions because I did intend to finish early because it's kind of the last main conference day but actually there right there I do I only take questions offline but actually for once I can take them in the flash present so are there any questions does anybody want to test the acoustics around here it's it's funny what happens when you take the chairs away they act as baffles when you take the chairs away something yes just like last year absolutely we just ignore no you just don't follow them blindly because lots of people come up with rules coming up with rules is really easy yeah and and sometimes sometimes they have the appropriate level of repentance one of the things that you'll find if you go through the dotnet naming conventions is this glorious single statement do not use Hungarian notation I say it's glorious because I had to I remember reading up on Hungarian notation which just to be clear was a Microsoft guideline so okay it's all I'm saying the point is they're making a guideline because they had to publish a book which had guidelines in it and they want to make you know there's a certain idea that you want to make it consistent but why is that guideline there as I said guidelines are cheap and easy but they're not always good they are not always well they are not always well thought out and we get them with we get them with spoken language and there's all it's nonsense about don't you know not ending sentences the prepositions and don't split infinitives and that's how to speak proper well actually no it isn't these rules were made up because people were worried that English didn't actually have any distinctive grammar so they made some up and they read my books and they got people they convince people that this was real no it's perfectly acceptable to boldly go where rules should be you know the point is that you need to understand why is this rule here don't just take the rule at face value why is it what problem does this rule solve now sometimes we may say alright okay so this class so in a java context this class is to be used as a Java Bean ah right it's used as a Java Bean I'm going to use gets and sets because that's actually part of the introspection protocol I have a good reason to do that now but unless it's going to be in that context and people don't really use Java beans anymore then why am I doing this what what what purpose does it serve so the idea is you need to work out why why is that why is this there and sometimes there is a good reason and although you might find it anomalous in other cases there is a good reason to follow it here and go there but you need to scratch the surface of a guideline find out why it's there and sometimes there's a good reason and some times as is then often the case with guidelines it's just somebody's arbitrary preference you know and that and the problem is that exception serves no meaningful value at all in this context and there are some names I mean I love the fact that if you use attribute if you define an attribute that Microsoft it that it'll tell you yeah you're supposed to put attribute in the name and you know how important actually it is it's so important that they'll automatically drop it they'll allow you to use the name without attribute that's how important the word attribute is it's not in other words what they've done is they've created they've created a guideline and then they've created a workaround for the guideline smart that's how you keep programmers in business so what I would say is guidelines guidelines can help because they offer guidance but the thing is that they can also guide you in completely the wrong direction I refer you to Hungarian notation I refer you to the Josh Bloch quote I refer you to the fact that the windows header files have you look at it from a sea perspective have gone from 16 to 32 to 64 bit and all the names are horribly wrong because they said you know what we're going to hard-code the bit sizes in all the names using Hungarian notation now you know they say oh well we learn from that no we learn from that in the 1970s and 1980s it was already a known problem yeah so therefore you have to scratch the surface go beyond it look at the reasons and maybe you will find that there is a sound reason to pursue it in other cases you go there just talking through their hand you know somebody got bored and said we need a convention for this absolutely well we could ask people to name exceptions as if they were bad things that's a great idea now I'm vetoing that we'll get a put exception on the end because they might not otherwise know it's an exception and they can put what the hell they want in front of the word exception okay I am parodying ever-so-slightly but there is that idea that you know that one has no value but there are name conventions that do have value just not one of them it doesn't work in reflection it's not it's not important yes yes is it being used for the same reason in the same way does it fulfill the same role and are all these are all these usages if you look at them are they similar in other words you can identify or are they mutually exclusive because sometimes that's the thing that you find oh it's one of those things I found in a lot of going back a lot of AP is for for file i/o for example you'd end up with a file and what can you do with the file you can read and write from it you know the number of cases where you actually read and write to the same file is incredibly rare people normally open a file full reading and in another piece of code they will open the file for writing in other words there are files we open for reading and files we open for writing an occasion there there are files we do actually read and write simultaneously on the same screen - in other words there it turns out that there are two disjoint roles and sometimes that's what you'll discover if you read so this is the idea as a naming exercise as a thought exercise sharpen it you suddenly discover this piece of code is using the same underlying object but actually from a completely different perspective to achieve a completely different thing and actually we have a name for that and suddenly you discover you have a new interface and it has half the things that were in the original more aggregated interface and you split it out to different roles so our idea of a role is very important and you may find the kinds of relationships we have are kind of mutually exclusive roles and an object a single class can implement two mutually exclusive roles so for example I can have something that is a listener but is also at some kind of event source so from one point of view we're just sending events to it but it we propagate s-- in a different sense and that usage doesn't care about that usage but it's the same object because it has the right information so there is this idea class can implement two mutually exclusive roles or independent roles sometimes the relationship between roles is that one role is an extension of another and so therefore you get subtyping of the interfaces so I would say look at it from that point of view and you will either find oh yeah they've all got a role and I can now think of a name for it or actually they're doing different things and maybe we have names to describe those different things okay yes don't you see that exceptions you are drawn to it like a moth to a flame yeah yeah yeah I mean this is the problem is that the who wrote these guidelines were written by human beings okay we're and these human beings that the you know I'm not going to say they're bad human beings because they're not because they're just human beings like me who make mistakes about certain things every now and then and occasionally have a good idea we'll see other people having a good idea and say I'd love I'd rather do that than that if you ask most people why they put why something is in a guideline you will find exactly as I said before scratch the surface and go in there and you'll discover that they have a kind of weird they'll either have a really weird view of how things should be or they're just following a habit that perhaps they've never had the opportunity to question yeah so there is this idea that we do very easily fall into habits without questioning them that's that's kind of part of being human so there's very good reasons we fall into habits without having to question them a lot of the time but here in software given that the stuff we're working with not real we need to be very very careful about how we use the few tools at our disposal names are really too valuable to be left to casual guidelines they become quite soulless after a while and you eventually lose the meaning the purpose of a name is not to follow a guideline the purpose of a name is to communicate what's going on in the code that is first and foremost within that space there are probably conventions and consistencies that we can find but if we are following conventions and consistencies at the expense of communication then those conventions and conventions and consistencies are worth very little they are holding us back rather than pushing us for right okay I'm going to call that time thank you very much

Channel: DevWeek Events

Views: 17,840

Rating: 4.9094338 out of 5

Keywords: Programming Language (Software Genre), Kevlin Henney, Software Development (Industry), Software (Industry)

Id: CzJ94TMPcD8

Length: 85min 22sec (5122 seconds)

Published: Mon Nov 02 2015