 Awesome. Hi, I'm Alana and this is Code Standards. I work with a company called Chromatic. We've got some swag up in the front and there's also a few of us here. We've got t-shirts if you want to talk to me or one of my co-workers at the end of the talk, we'd be happy to hook you up with one of them. We're a pretty small company. You can find us at chromatichq.com or at chromatichq.com on Twitter. It's a little cut off there. You can find me at aburk626 on Twitter or dripple.org, so here we go, Code Standards. It's okay to be yourself, but write your code like everyone else. And just a note, there's a lot to cover here and a lot of links, so I'll make these slides available right after the talk and I'm going to go pretty quickly, so don't worry about taking notes or trying to write down the links. I'm also going to make sure that you get the links to the series of blog posts that I wrote which inspired me to do this talk. Some of them go a little more in-depth and give some more examples as I only have so much time here. So what are coding standards? Standard. A level of quality or attainment. I find it useful to divide standards into two types, style, which includes things like indentation, spacing, line length, and substance, which includes things like correct use of functions and components. Why are they important? In a blog post from 2004, PHP developer Paul Jones writes, the point of a coding style standard is not to say one style is objectively better than another in the sense of the specific details. Instead, the point is to set up known expectations on how code is going to look. Code standards are important for a lot of reasons. They keep your code readable. You can spend less time worrying about what your code looks like and more time coding. It helps bridge the gap between coders of different backgrounds, languages, and locations, which is especially important in open source software projects such as Drupal where developers from around the world work on the same code. It's also important for automation and we'll get into this a little more later. Who decides coding standards? Well, we do. Standards are decided by the Drupal community. How are they decided? Drupal standards are based on the pair coding standards and they're decided in an issue queue on Drupal.org. So if you're ever interested in checking that out, there are a ton of people who get really into it. It's kind of fascinating to see how these little tiny minutia can result in these huge discussions but eventually someone decides on it and it becomes a standard and it goes into the documentation. So now that we've gotten some basic questions out of the way, let's talk about how we implement coding standards in our projects. So the first thing that I have to recommend is to read the coding standards and keep them handy. As Drupal's code is changed and updated, so are the coding standards. They're like a living document. So make sure that you bookmark them and periodically review them for changes and updates. And you can find them at Drupal.org slash coding standards. The next thing is to set up your editor for success and let it do the work. There is a lot of documentation out there for using editors, specifically with Drupal, especially for sublime text and PHP Storm, but other editors as well. Look for this, set up your editor, and save yourself some work. One of the easiest ways to implement coding standards is to review your own code with the coder module, which implements PHP code sniffers specifically for Drupal. So here's an example of running it with the shortcut Drupal CS on a file in the country's control module and getting a list of errors back, so I know what to fix. There's also a link here to a great post by one of my coworkers about enforcing coding standards with PHP code sniffer. Team code reviews are another important way to enforce code standards. You have to make the time for them. The most successful teams build in time to review one another's code. There's no substitute for code reviews by another person. Make sure that you view them as an essential part of your process. And yet again, I'll link by one of my coworkers to a blog post explaining why code reviews are worth their weight in gold. It's really important to us at Chromatic. When reviewing code, whether it's yours or someone on your team, on Drupal.org or on GitHub, make sure to remember these two things. Treat others as you would like to be treated. Be kind, courteous, respectful, and constructive. Be aware of your tone. When we're typing things online, it can be really hard to get your tone across. So reread what you write. Take everything in stride and don't take it personally. Those reviewing your code want it to be good. And corrections aren't a personal attack. Next, let's talk about formatting. If you watch the show Silicon Valley, you may recall the episode where Winnie and Richard break up because she uses faces and he uses tabs. In researching this talk, I found that yes, people do feel that strongly about it. Lucky for us Drupal folks, it's already been decided. Two spaces. This is really easy to set up, for example, in sublime text. Don't have to worry about it. Some other white space standards, no trailing white space. This means no spaces or tabs after the end of a line. This can also be set up in your editor. Use blank lines sparingly to keep crowded code readable, if necessary, but try to avoid extra blank lines throughout your files and functions. When it comes to file endings, Drupal uses Unix file endings. If you're not aware, the difference between Windows and Unix file endings is just what characters are put to indicate that it's the end of the file. There must be a single blank line at the end of each file. And this is another thing that most text editors can do for you. Next up is arrays. In Drupal we have some new short array syntax standards that are specifically for Drupal 8, but they can also apply to Drupal 7 if you're using PHP 5.4 or higher. Essentially, the new short array syntax replaces the word array and the parentheses with square brackets. So you can see, in the example of the new one, we've just got square brackets around our array items. And the old arrays are wrapped in parentheses with the word array. So just be aware of this, it's not supported in versions of PHP prior to 5.4, but you will be using it in Drupal 8. So line length in arrays, if you have an array declaration that's longer than 80 characters, split it into a multi-line array like this. And this example is also using the new short array syntax, but multi-line arrays work the same way whether you're using the old long array syntax or the new short array syntax. Each item is on its own line. Each item is followed by a comma, including the last item. And this is Drupal best practice regarding arrays in PHP. And some things to think about. If you have a super long array that's hundreds of items, you could break each item into its own line. It'll be very, very long, but very readable. But if the programmer who looks at this code next is unlikely to need this info with their fingertips, maybe it's a list of zip codes or states or something like that, consider importing it from a CSV file or similar and keeping it out of your code. Now let's talk about line length in general. Line length, lines should be 80 characters long. If breaking up your code over multiple lines, however, makes it less readable, reconsider. The goal here is readability. Comment and documentation text, however, should always be 80 characters and under. And here's an example of how easy it is to set up a ruler in your editor. This is sublime text, operators. We use these all the time. There should always be one space around operators. Here are some examples. But you do not need spaces just inside of parentheses. To show why we put spaces around operators, here's an example without the proper spaces. Using the ternary operator in general can be hard to read in the first place. Without spaces, it becomes much harder to see what's going on. With spaces, it's suddenly much clearer. We can see that this is saying, if A equals system or B equals system, and then the ternary and the return statement is saying, if A equals system, return negative one, otherwise return one. It's so much harder to figure out in that first example without the spaces, what's going on. Function calls and declarations. When declaring a function, there should always be a single space after the argument list and before the opening curly brace. The function then begins on the next line indented with two spaces. Closing brace always goes on its own line. A function call has a set of parentheses with no spaces on either side of them, whether or not there are parameters. If there are parameters, they're separated by a comma and followed by a space. This is all pretty basic, but we want to explain it. This is an update hook from the advanced form contrib module. It's a simple example of both a function declaration and a function call. So here we're declaring the function advanced form update 7200. You can see that there's a set of parentheses with no spaces before them. One space and an opening brace. Inside the if statement, we can then see the function call to variable set, with no space before the opening parentheses. The arguments separated by a comma and a space. Again, basic, but good to start here. Constants. Notice the all caps in the previous slide on null and false. True, false, and null are always capitalized in Drupal code. Constants, always all caps. Custom constants must be prefixed with the module name. Here's an example from the CK editor module. Each of these defined constants is prefixed with the module name, CK editor, and is in all caps. When using control structures, like if, else, else if, case, switch for each, while, do, etc., there should always be a space after the control structure term. This is one that I see mistakes with a lot because a lot of languages do this differently. There should always be a space before the opening curly brace. The statement is indented on the next line, and the closing brace is on its own line, much like functions. Inline control structures are not permitted in Drupal, although they are valid PHP. So you should not use either of the following structures in Drupal. First one, everything is on the first line with no curly braces. The second one, I put the statement on the second line, but still no curly braces. These are both valid PHP, but they're not using Drupal standards. Control structures must always have braces, and the statements must always be on the next line. And note that in Drupal, the standard is to use else if as one word, not else if as two words. Again, both are valid PHP, but the Drupal standards specify it as one word. We use an alternate control statement syntax for theme templates. Use if with your statement and parentheses, a colon and if on the next line, a semicolon without braces. I'll show one example on the next page. Statements must still be on their own line as must the end if statement. So here's an example. We've got our if statement. On the next line, we have this code to execute. Then on the last line, we have the end if and a semicolon. So this is only valid to use in theme templates. Casting. So this is something that I feel like I don't use a lot and yet I run into these errors pretty often. The type is always wrapped in parentheses. You always put a space between the type and the variable. So we've got an example here from the big menu contrib module. So we're actually casting this variable twice to an int and then to a string. And note that there's a space after string and again after int. This one you probably know but it's so important it gets its own slide. Every PHP statement ends with a semicolon, always. And PHP tags. All PHP files begin with an opening tag but never ever use a closing tag. We also never want to use PHP short tags in Drupal. Why? Because white space or other characters after a closing tag can cause errors. So allowing PHP to close it on its own eliminates those errors. Now we're gonna talk about documentation. Why is documentation important? It tells us what to expect from our code much like code standards themselves. But I know what my code does, you're thinking. Sure you do. Right now. Because you just wrote it. But how about in two months or 10 projects from now? Will someone else know what you meant? The key is to make your code maintainable by everyone. Of course ideally you're writing code that's easy to comprehend because you did everything in a perfectly logical and straightforward way. But comment it thoroughly just in case. You might also do something clever to solve a tricky problem but to the next person it could look like a mistake and documentation can help clear this up. But my code is so good it's self-documenting. Of course it is. But even to the best programmer, documentation is still quicker and easier to read than code. Documentation is especially helpful for beginner programmers. Say someone who's just starting out with Drupal and PHP who's looking through your code to see if it does what they need. If you can spell it out for them you'll help them figure out what it is they need a lot faster. And thanks to Drupal's documentation standards we have a few ways to document your code that are designed to be quick and easy for the developer writing the code and the developer's reading and modifying it. That said, try to avoid repetitive inline comments. You don't need to comment on every single line of code especially if it's very clear what it's doing. Comment on functions, on large blocks of code, things that may change and try to think about what might be unclear to the next person who looks at it. Doc blocks. These are specially formatted blocks of information that go both at the top of each PHP file and before each function. File doc blocks go at the top of a file to give you an overview of what the file contains. There should be one blank line before the opening PHP tag and the doc block and the first line should be file. On the next line after the file tag we have a short description. The file doc block may also commonly include author and version tags. So here's a great example from the backup and migrate module. It's short and simple. It explains what to expect in this module file. Each function will be documented separately so this doesn't need to be extensive. We have the PHP tag, a blank line, we have the file tag, and then we have a two line description. In something like a template file you'll see more detail in the file doc block because the rest of the file may not have as much documentation. And the file doc block may often spell out all of the available variables. A function doc block goes just before every function in every PHP file. There are no exceptions ever. Only a one line description is required and you should include any parameters and return types. Here's a great example. Now a function doc block with only a one line summary will pass coder but it's lacking important information. Now, does this take a little more time? Absolutely. But I guarantee that you will have a better understanding of your code if you write out the documentation in as much detail as possible. Now, we know what's passed to the function, what each variable is, and what the function returns. Good documentation can also aid in debugging. If the documentation doesn't match what's happening in the code, you know something's wrong and you've got a starting point for fixing it. There are a variety of tags you can use in your doc blocks and they go in a certain order. We have a one line summary ending in a period, additional paragraphs of information. We have a var tag, param, return, throws in group, deprecated, see to do, and then we have plugin and some other annotations. Groups and topics are tags that come from Doxygen on which these standards are based and it helps to group generated documentation for the API module. The deprecated tag can be really useful if you don't wanna delete a function but it's no longer the most up to date and someone could have custom code that relies on it. So each type of tag should be separated by a blank line and the most used tags are probably param and return. Here's an example of how the country's module uses some of these other tags. So here the description tells us that they're generating a country form which is in group forms and then they tell us to reference see these other functions which are countries admin form validate and countries admin form submit. So when you're implementing a hook like hook menu, all you have to put is implements hook menu. If you put more than this, Coder will give you a warning like format should be implements hook foo. It's also gonna tell you a lot of stuff that is technically not always correct but it's going to yell at you. Don't duplicate function documentation. You will get a warning like hook implementation should not duplicate param documentation. If it's really important that you document something that has changed in your hook implementation, don't skimp on the documentation but you can always put that documentation inside the function if you wanna keep Coder happy about the doc block. Now, why are these doc blocks so important and why do they have to be formatted so exactly? Well, the API module parses the information in doc blocks into human readable documentation. All of the documentation found at api.druple.org is generated this way. Let's talk a little about inline comments. Drupal generally uses C++ style notation with two slashes. C style comments with a slash and a star are allowed but they're discouraged within functions. Inline comments should not follow a statement. This means they get their own line and inline comments must always end in a full stop. So always use a period, an exclamation point if you're excited about it, a question mark and they must never be longer than 80 characters. Also, it's usually understood that a comment precedes the line that it's commenting on, but you can always make this clearer by saying something like the following line does x, y, z. And finally, something that I only found out when I was researching this is that Drupal has a style guide for content. It's style of various industry related terms like how the word Drupal should be used and what should be capitalized. And you can find this at, and this link is not wrong. It's just weird looking. Drupal.org slash Drupal.org slash style guide slash content and again, I'll post these slides. So the next thing I wanna talk about is the translate or t function which is a very widely used and misused function, so much so that I think I need its own section. So what does it do? It translates a given string to a given language at runtime if you have more than one language enabled and this allows for localization. You wrap all of your user-facing strings in this function so that they can be translated. And depending on which placeholder you use, it runs different sanitization functions. So when and where do you use it? Pretty much everywhere. Every user-facing string. This ensures that your site can be localized. When in doubt, translate everything. You might be coding and thinking, oh, the string will never be translated, but two years later, when you're trying to find a string that's showing up untranslated on the site and your stakeholders want it changed, you will be much happier if it's already ready to translate and I am speaking from experience here. So the parameters for the t function, there's three of them, two of which are optional. The first is the string to be translated. The second is an array of replacements and the third is an array of options. So the options array isn't often used. Let's dig into it a little bit. From Drupal.org, this is an associative array of additional options with the following elements. The lang code, which defaults to the current language, and it's the language code to translate to a language other than what is used to display the page. And the context, which is interesting, is a string giving the context that the source string belongs to. So what is this? String context is a way to organize translations in words have one to many translations. So each original English string can only have one translation, which makes sense. But this is a problem when an English word has several meanings, like order, which can mean the order of elements in a list to order something in a shop or an order someone has placed in a shop. For many languages, the string order needs a different translation for each of those meanings. So this is where you would use string context, and you can read more about actually implementing it on Drupal.org, but I wanted to mention it here. Placeholders. They come from the format string function, which is called by the t function. The most common placeholder is probably at variable. This placeholder runs check plane on the text before replacing it. And you never want to pass a variable through t directly, only string literals. Now, the short explanation for this is that the string to be translated needs to be available at runtime. And the variable may not be available and may change its value. So I found a really in-depth explanation on Stack Exchange. This was a really great discussion. So if you want to check out this link later, highly recommend it. So how do we use placeholders? You use it to insert a value into the translated text. Like in this example from the advanced form contrib module. Here we see the at forum placeholder inserting the forum name value into the string. We also have the percent variable placeholder. This runs Drupal placeholder on the text, escapes the text, and formats it as emphasize text. There's the exclamation variable placeholder. In Drupal 7, this inserts your value exactly as is without running any sanitization functions. So you would never want to use this on user entered text and only on text that has already been properly escaped. So in Drupal 8, exclamation variable is deprecated as there's no longer a placeholder for unsanitized text because it's not really a good idea. New on Drupal 8 is colon variable for use specifically with URLs. In Drupal 8, colon variable is escaped with this function Drupal component utility HTML escape. And it's also filtered for any dangerous protocols using URL helpers, dangerous protocols. So this is a great way to make sure that any URLs you are using are nice and safe in your code. So when don't I use the t function? In Drupal 7, there are a couple instances when it's not available. During the installation phase, t isn't available. So you have to use this get t function. You can do something like this. You set a variable to get t and then wrap a string in that. It's a little awkward. Translation is also not used inside of a hook schema or hook menu. But in Drupal 8, it's available all the time so you can always use it. So the next section, I'm gonna show some bad examples of using t and links because this is one of the places where I find people get sort of the most confused in how it should be used. There are a lot of ways to do this and a lot of them are really over complicated that I've seen. These are all sort of abstracted but these are all actual examples that I have seen. I just rewrote all of the words in them. So don't concatenate like t strings around a link like this. That's just a really strange and silly thing to do. Don't use a variable to insert the entire URL and its HTML markup into the text. It's just sort of weird and you could use probably the L function instead or there's a couple of different ways you could go about that. And also don't insert the entire thing directly into t. You would wanna do something, especially interblate, you would wanna do something with that URL. And don't, I have actually seen this, don't insert the L function and the t function, you could use one or the other but using them together like this, very awkward. It's not, it's just redundant and over complicated. Good way to do it. Use the t function and a placeholder to just insert the URL into your string. This is good, this is simple. Here's an example from Drupal 8 core using both percent variable, which we recall runs Drupal placeholder on the text, escapes it and formats it as emphasize text and then using colon variable on the URL which strips the URL for dangerous protocols. We can also see that the link markup is inserted into the t function, which is okay. If you can avoid putting any markup into the t function, that's great, but not at the expense of making overly complex and difficult to translate chunks of code, it's better to just put a little HTML in your t function if you can't avoid it. So some best practices. Writing your code and content to be translatable, it isn't just a best practice but it may very well be used to actually translate your site. So sometimes you need to think from the point of view of a translator. Try not to abstract out your pieces of content too much. So for an example, if you had a blog titled Bob's Homepage, your instinct might be to abstract it out like this, the username concatenated with an apostrophe s and then the translated homepage. So what's the problem here? In other languages, this phrase might be rearranged. For example, in French or Spanish, it would be homepage de Bob. And this example that we have would require a translator to change code. So what's the solution? Less abstraction. Translate this whole chunk. User with placeholder users, apostrophe homepage, apostrophe s homepage. This can easily be changed without coding to placeholder homepage de placeholder user. And then we just insert the username in here. And this doesn't require the translator to change any code at all. Just rearranging the words. In the example in the previous section, we showed where concatenating a translated string with another string can make some trouble. There's some other things you wanna avoid. Both of these examples could be avoided by using one T function and placeholders and no concatenation. Again, these are things that I have seen trying to concatenate strings within T instead of just having all of this wrapped in T with none of this concatenation and just replacing just having that one replacement. And then the second one, you absolutely don't ever need to concatenate T strings and variables. You can just replace my string with a placeholder. This would also give you a code sniffer error because you should never have leading or trailing white space in a translatable string. So do this. Here's a simple way to join my string and translated strings by using a replacement. This is how the T function is designed to be used. So in Drupal 8, the essential function and its use are the same. You wrap your text in your module code in T with the same optional placeholder and options arrays. As noted in the placeholder section, exclamation variable is deprecated and replaced with colon variable. But in Drupal 8, we also now have the twig templating engine. This means new ways to format our text for translation in templates. The simplest way is to pipe your text through T. Here's an example from the control module where we have a handful of strings and then just pipe T. This is exactly the same as T parentheses string. So the text is just piped into the translation function just as it will be passed through T. You can also use pipe trans interchangeably with pipe T. And you can use a trans block in twig to translate a larger chunk of text or to use placeholders. These blocks can also handle logic for plurals, which is really cool. Here's an example from Drupal 8 Core where we have if displays, trans. So we're translating all of this and then we have display for the singular. Plural displays, displays, and then entrans. So it's that easy to translate and handle plurals in your theming in twig and Drupal 8. So wrapping up, we've gone over a lot of what not to do, I know, but you're gonna run into a lot of creatively incorrect code when it comes to translation. And I think now you're going to know it when you see it. Simple is best. Remember that this function exists to give translators a list of strings to translate. And now you'll be in the right frame of mind when assembling these strings to keep them flexible and translatable. There's also more to dig into with twig and translations and logic in Drupal 8 if you wanna look into that on Drupal.org. Next up, we're gonna talk a little bit about object-oriented coding and Drupal 8 standards. So object-oriented programming, or OOP, is a way of programming that is based on the concept of objects, which represent data in a program. Objects have properties which hold data and methods which execute functions. After an object is created or instantiated, it can be used over and over again. OOP allows for a lot of reuse and convenience that procedural programming does not. If you're not yet familiar with Drupal 8 and OOP, you may want to brush up because we're going over the best practices and formatting here and not concepts. So the OOP examples project on Drupal.org may be very helpful. And a note, all of these examples are from Drupal 8. And while you can certainly use object-oriented code in Drupal 7, and many people have, it's now mandatory, so get used to it. Also, I started gathering some of these examples several months ago, and it's possible that they could be slightly out of date, so if you happen to maintain any of these modules and this is your code and it's out of date, I apologize. So let's start with classes. Declaring classes, there should be only one class, interface or trait per file. And the file should be named after the class or interface. An example from the Ctools contrib module. This file is called entity-form-wizard-base.php. The class is called entity-form-wizard-base. This is really straightforward and probably something you've already been doing if you've ever created a class file. I'm sorry, some of these are a little cutoff even though I officially know they're the right size. Class naming is important for auto-loading. Auto-loading allows for classes to be loaded on demand instead of a long list of require statements. So from Drupal.org we have, in Drupal 8, classes will be auto-loaded based on the PSR4 namespacing convention. In core, the PSR4 tree starts under core slash lib. In modules, including contrib, custom, and those in core, the PSR4 tree starts under module name slash SRC. So this is just explaining how the structure of your modules should go. And from the PSR4 auto-loader documentation, which is actually really brief and worth looking over, this PSR describes the specification for auto-loading classes from file paths. This PSR also describes where to place files that will be auto-loaded according to the specification. So all that's going on here is that PSR4 is telling you how to create your file paths so that classes can be auto-loaded. Most of what matters here is how you name and arrange your files and directories. The rest is already happening for you behind the scenes. And a note on the file doc block in Drupal 8. The current Drupal standards state, the file doc block must be present for all PHP files with one exception. Files that contain a namespaced class interface or treat whose file name is in the class with a PHP extension and whose file path is closely related to the namespace under PSR4 or a similar standard should not have a file documentation block. So like the example that we just looked at where the name of the file and the class were exactly the same. As long as that's the namespace and the path were also the same, it didn't need a file documentation block because we already knew what the name of the file was. This was adopted after most of the Drupal 8 code was written, another reason to keep your code standards handy. So this is why you are still seeing file blocks in PHP files that don't actually require them. I haven't edited any of the snippets that I'm quoting here. Be aware that this is a new standard and you will probably be seeing this adopted in module code. Namespaces are a way of organizing code bases. So first let's look at an example of a namespace from the meta tag contrib module. So the file doc block here, which again probably would not be needed but is helpful for learning, tells us that this file contains a class called Drupal slash meta tag slash command slash generate group command. And then we see the namespace declaration for Drupal slash meta tag slash command and the documentation and declaration for the class generate group command. So you can kind of see how all of these names trickle down. And if we look at the directory structure and this was a screenshot of my directory, you can see under meta tag there's command generate group command. And remember that the PSR for directory tree starts under SRC. So SRC is not included in the namespace itself. So whenever you make a Drupal module in Drupal 8, you follow the directory structure module name slash SRC slash your namespace. So here we have meta tag SRC command. So in the example that we were just looking at, there was a whole list of classes that were going to be used in this file. And any class or interface with a backslash in it must be declared like this at the top of the file. There's a whole handful of them. These are called fully qualified namespaces and they can now be referred to by just the last part of the namespace. And the fully qualified namespace may no longer be used inside the code. In the class generate group command, the use statements here, you can see at the bottom, you can't really see at the bottom because it got cut off, but those all say use in front of them. They refer to the same namespaces used at the top of the file, but they were not using the entire name. No backslashes. Also, there's only one class per use statement. You say use this class, use this class. There's not a whole list of them. And if you have two classes with the same name, that's called a collision and we fix it by aliasing the namespace. You use the next higher portion of the namespace to create the alias. So here we've got two extension manager interface classes being called and they're at alias to reader manager interface and writer manager interface since they're zen slash feed slash reader and zen slash feed slash writer. Actually, that doesn't happen a lot. FYI, it took a long time to find an example, but if it happens, that's how you handle it. An exception to use statements is if you are trying to use a global class. In that case, you don't need to use anything at all. Here's an example from the development module. So in this function format time, we can see throw new invalid argument exception. So that's not declared anywhere in the file because it's a global class. It's a part of Drupal core. In fact, it's a part of symphony on which Drupal 8 is built. If you're curious, it's symphony component, dependency, injection, exception, invalid argument exception. Now you know, remember that there's a quiz. Indenting and whitespace. Formatting basics do not change in object-oriented programming, but there are some specific conventions. There should be an empty line between the start of a class or interface definition and a property or method definition. So here's a token-contrib-module example. So the code declares an interface, token entity-mapper interface, and then leaves a blank line before the function declaration. So blank line and then, again, the beginning is cut off, but that's the function dot block and then the beginning of the function declaration. Indenting and whitespace. There should be an empty line between a property definition and a method definition. So again, from the token-contrib-module, we've got this code declaring a property, entity-mappings, and then a blank line before the function definition for the constructor here. Some of those are hard to remember, so I have those bookmarked. A lot of just differences in adding blank lines where they were not in Drupal 7. Indenting and whitespace. There should also be a blank line between the end of a method definition and the end of a class definition, also very new. So there's a blank line between your ending curly braces. So again, in the token-module, you can see that there's a blank line. This is at the end of the file, there's a blank line between this very last function and then the last curly brace. There's also a few naming conventions that are different. When you're declaring a class or interface, you always use upper camel, but if you're declaring a method or a class property, use lower camel. Class names should never include Drupal or class, and interfaces should end with interface, test classes should end with test. There's a whole bunch more detailed conventions at Drupal.org. Here's a nice example from the Google Analytics module. There's a bunch of properly named classes here, including Google Analytics tests slash Google Analytics basic test. We've got an account interface, a web, or they're using an interface, and we've got a class Google Analytics basic test extends web test base. They're using upper camel for the classes interfaces. These can be a little tricky to understand, but for flexibility reasons, you strongly encourage that you create interface definitions and implement them in separate classes. If there was the remote possibility of a class being swapped out for another implementation at some point in the future, split the method definitions off into a formal interface. A class that is intended to be extended must always provide an interface that other classes can implement rather than forcing them to extend the base class. Well, here's an example where we have an interface and then a class implementation. Excuse me, this is from the C tools module. So we've got constraint condition interface declared, and then it's got two functions, apply constraints and remove constraints. So we're not doing anything with this, we're just declaring all of it. Visibility, all methods and properties of classes must have their visibility declared. They can be public, protected, or private, but public properties are strongly discouraged. An example from the meta tag control module, this code declares a protected property token and a public function construct, which I think you can see all the way at the bottom. Type hinting is optional, but recommended. It can be a great debugging tool. If an object of the incorrect type is passed, an error will be thrown. If a methods parameters expect a certain interface, specify it. Do not specify a class as a type, only an interface. This ensures that you are checking for a type, but it keeps your code fluid by not adhering rigidly to a class. So interfaces really help us to put some constraints on things, but not to make it so constrained that we can't continue to use our code and reuse it for other purposes. Keeps code reusable by checking for the interface and not the class, allowing classes to differ. So here's an example from the path auto contrived module. In this code, we have the property definitions function, which has the parameter field definition, which is sort of running off the edge of the screen there, and it has the type hint, field storage definition interface. So we're using an interface here instead of a class. So there could be a variety of different implementations of that interface, and they would all pass here. Chaining is my favorite thing, and it allows you to immediately call a function on a returned object. You're probably really familiar with this with database objects. We've got this example from the develop node access contrived module, where the results of DB query are chained into fetch field. Without chaining, you'd have to set the results of that query into an object like result, and then you could use the fetch field function in another statement. To allow for chaining whenever possible, methods that don't return a specific value should return this, especially in methods that set a state or property on an object. Returning the object itself is much more useful than returning a Boolean or null because if you're trying to chain things, you're just kind of going to cut it off and you're not going to get any valuable information out of that. Constructors and instantiation. Drupal's coding standards discourage directly creating classes. Instead, it is ideal to create a function to instantiate the object and return it. Two reasons are given for this. One, the function can be written to be reused to return different objects with the same interface as needed. And because you cannot chain constructors in PHP, but you can chain the returned object from a function. And as we said before, chaining is my favorite thing. So here's an example from the meta tag contrived module. It's a function that returns a new instance of a meta tag generator. The create generator function is declared in an interface that is implemented by this class. So this wraps up the object oriented programming section. If you need more resources, when I post this, you can check out these links. They've been really helpful to our team. Along with, as I mentioned before, the OOP examples module, which is not really a module in and of itself, but it's a bunch of code examples. Next up, twig and Drupal 8. Twig files should include a doc block, like any other Drupal file. Sections such as C, in-group, et cetera, still apply as they did before twig, so used as appropriate. One note on in-group themeable from Drupal.org. Twig template doc blocks should only include in-group themeable if the template is providing the default themeable output. For themes overriding the default output, the in-group themeable line should not be included. So it only gets the in-group themeable tag if this is the default output. Lints are wrapped in the twig comment indicator, which is the pound sign inside of curly braces. Short and long comments use the same indicator. Long comments should be wrapped so that they don't exceed 80 characters. And comments that span several lines have the indicators on separate lines. So here's a quick example of a short comment from Drupal 8 Core in the field UI module, very straightforward. And an example of a long comment, this is from the book module in Drupal 8 Core. As you can see, the comment indicators are on separate lines and the text is indented. Variables should be referred to only by name in the doc block with no prefix. So if you had a variable named foo, you wouldn't use the dollar sign or curly braces around it. The type shouldn't be included in the doc block, doesn't have anything to do with theming. And variables referenced inline in a doc block, meaning like inside of a sentence should be wrapped in single quotes. So here's an example from the token module which heartbreakingly is also cut off. So in this code, if it's not completely cut off, you can see that the doc block lists the available variables. It says like URL, text, attributes, and link. So they're listed without a prefix or a type. And this is the default template, so it uses in group themable. You can also notice that there is no period at the end of any line that starts with a tag. So variables referenced inline in a doc block are wrapped in single quotes. This code is from comment.html.twig, which is a really, really, really long doc block. But in this snippet, we can see that these variables are properly referenced and wrapped in single quotes. If you look in the third line, we have the desired parameters on the comment.created variable. So that's how you would want to reference a variable inside of a sentence in a doc block. Expressions, this is so fun. Twig makes it really easy to check if a variable is available before using it, just use if, how sensible. Here's an example from jubilate core. So in this code, we can see that the code checks for the availability of label with if label before printing it. This is a lot simpler than previous methods of checking, which required much more complex structures and much more code. Expressions, loops are also much simpler in twig. You can easily use for loops in twig. So here's an example from the develop and trip module. This code loops through and prints out each item in collector.links. You can also do for each loops, which I don't have an example of here, but I do in my blog post online. It's incredible how much easier this stuff is to do in twig. Another simple expression that can be done in twig is variable assignment. If a variable is needed only in the template, you can just declare it directly, as you would anywhere else. You literally just say my variable equals my variable value. Done. HTML attributes in Drupal 8 are drillable. They can be printed all at once or one at a time using dot notation. If you don't print them all, they should all be included at the end so that any other attributes added by other modules will be included. If you're not familiar with HTML attributes in Drupal, check it out in the Drupal.org documentation and the Drupal twig documentation on HTML attributes. Here's an example where in this code the full attributes are printed for the A and the spam tag. We've got A attributes name extra and span attributes name extra. You can also add or remove a class in twig. Here's an example from the views module. In this code, an array of classes is created and then added to the HTML attributes. This is also a thing that could be much more complicated and twig makes it a whole lot easier. Whitespace control, this is another thing in twig, I think it's super cool. The spaceless tag removes whitespace between HTML tags. So wrap your code in this tag whenever you want to remove whitespace. So here, this entire chunk of code is wrapped in the spaceless tags, which are cut off here. The whitespace control character, which is just a hyphen, removes whitespace at the tag level. Here's an example in Drupal 8 core and you just, it's just added to the delimiter. So we can see that the whitespace control character is added to the delimiter as indicating the whitespace should be removed on both sides. Because you can also use it to remove the space from just one side if the whitespace character is only added to the delimiter on one side or the other. Caveat regarding new lines at the end of files. Drupal coding standards require that all files have a new line at the end of the file. But if you have PHP code sniffer or any other test setup for Drupal, it's going to require this. In twig, you may not want this in your template output until a better community-wide solution is reached. You may want to alter your tests to get them to pass or there are some twig template tags you can add to the end of your file. There's an ongoing issue here for more clarification and how to do this. It's not that complex, but it is a little annoying. A filter in twig uses the pipe character. We talked about this with the t function to translate, but there are other filters that you can use as well. Here's an example of a twig filter join from Drupal 8 core. So in this code, the join filter is applied to collector.rolls, which concatenates the items, separates them with a comma and a space as indicated. So that's a pretty cool thing. Very simple to use. So there's some nitty gritty details. I'm just going to go over real quick for syntax. I don't have examples for all of them since I don't have another hour or a few more minutes, but there are examples online. Again, you can see them when I post the slides. So these standards are taken from the twig documentation at sensiolabs.org. Put one and only one space after the start of any of the twig delimiters and before the end of a delimiter. And when using the white space control character, you never want to put a space between that character and the delimiter. Put one and only one space before and after all of the following operators. So we have comparison operators, math operators, logic operators like not and and or. A tilde is in and the ternary operator. Put one and only one space after the colon sign and hashes, the comma in arrays and hashes. Do not put any spaces after an opening parenthesis or before a closing parenthesis and expressions. Do not put any spaces before and after the string delimiters. And do not put any spaces before after these following operators, the pipe dot, two dots and the square brackets. Do not put any spaces before and after the parenthesis used for filters and function calls. Do not put any spaces before and after the opening and closing of arrays and hashes. Use lowercase and underscored variable names. And indent your code using two spaces as throughout Drupal. So to wrap up the presentation, remember to keep your coding standards handy. Refer to them often, they change. Check out the coding standards, issue queue and keep your code clean. Thank you. If anyone has any questions, we're out of time but you can find me, I'll be either in the back of the room or just outside. For what was that? I don't have them up yet, I'm just, I'm gonna put them on the page for the session. Yeah, I'll put it up in a couple of minutes as soon as I can. Thank you. Can't be a tabber. Because it's the rules. Like I know I'm all about diversity and inclusion but we don't, not if you're a tabber. Sorry, we can't have you here. I did a tabber with two hours and I found out it's because I had a tab and it wasn't meeting it. Like it's great, it's awesome.