You can listen to the podcast and read the show notes here.
Michael: Welcome back to the show. I'm here with Kai Koenig, and he’s joining us from New Zealand where it's just after 6:00 a.m. which is very dedicated of him to the ColdFusion community. And we're going to be talking about some tools for improving your ColdFusion code quality, and we'll look at why this code quality matter, and what it means in practice. And we'll look at some different things you can do to measure your code quality without running the code.
And also, we’ll examine why there are more tools in other languages than CFML in this field, and what Kai is doing to remedy this with the C.F. Lindt project and we’ll dig into that in a bit more detail. And if you haven't met Kai, he's been in the ColdFusion community for nearly 20 years now. I think I met him out a C.F. Europe event many years ago. And he works for [inaudible] [00:53] in Wellington, New Zealand. And he doesn't whole a bunch of things from ColdFusion, to Flex, to Java, all kinds of stuff; maybe we'll talk about that a bit later. So welcome Kai.
Kai: Welcome Michael, thanks for having me, good morning.
Michael: Yes, good… well evening for me, but morning for you. So, let's just start off because people may not have thought about this at all. Why does code quality matter?
Kai: Because in reality, when you write code – I mean regardless what language or technology you're using. You usually writing code that lives quite a long time. And what that means is like you might have to go back to your code in a few weeks, a few months, a few years. And all of us when you look at that and you would think like, “Woo, what was that?”
And till you look at it on the carrier locks all the indications for that line of code to figure out oh, it wasn't like you know two years ago, oh no. And I mean that is really the simplest explanation why code quality matters. You want to always ideally produce code that can be maintained, that can be no looked at, understood in a couple of years of you know, who inflated at least, and that is well documented and that just makes sense. And that really is cold quality to some extent or a very high level description of what cold quality.
Michael: And presumably, it reduces the number of bugs in your code as well.
Kai: Well, yeah, that's kind of a welcome side effect of that, right. I mean depending on how it's fine code for you or for your team. You know how you define a good code quality. That could mean that you basically say, I want certain tools against my code, and I expect you know. Let’s say all unit tests to pass or you know less than one percent of unit tests to fail, or certain cold checking rules to be okay, or again within a certain threshold off like being successfully checked.
And yeah, side effect of that is usually you have less box or less problems in your code. Not necessarily bugs. But you know just like things that don't look right and I mean that's another thing we could talk about like cold smelts. You look at some code of yourself, or you know by someone else. You think like ah, something's not quite right with that code, and usually means something is actually not quite right.
Michael: Yeah, I wrote a whole blog post on code smell. So, I'll link that into the in ColdFusion. I'll link that into the show notes. But code smell is basically some rules of [inaudible] [03:58], the code is off. Is that how you’re using the term or?
Kai: Yeah, I guess that’s about right. I mean it's more… I would probably say it's that gut feeling that something is not okay. I’m sure people have tried to put that into like rules, like what are bad smells basically and [inaudible] in architecture as well. You don't have to go down that semi-formal path. Sometimes, it's literally good enough to just look at something and think like, yeah that's okay. And then you dig deeper and you find whole flurry of problems coming from that. I just recently looked at some code that was throwing crazy arrows in an application log file. And there was a production and no one actually ever mentioned, ever monitored that particular log file.
Kai: And so, we looked into the code, it was kind of reducing that arrow. And turns out that was actually an arrow that was masking a whole bunch of other problems. So we took that you know [inaudible] stuff out of the code. And all of a sudden, hell breaks loose; that kind of thing it's like oh, okay. That is a serious problem, and sometimes you find those things. This little thing that’s kind of off. And all of a sudden, you uncover actually a big issue.
Michael: Yeah, it’s sort of like dealing with cockroaches in a house. If you've ever lived in the south of the United States. You lift up a little cardboard thing, and there's a few cockroaches there, and then you lift something else and as a whole zoo of cockroaches.
Kai: I think people [inaudible] [05:42] if you can see a mouse or rat in your house and that’s actually bad because there may be probably 50 others.
Michael: Yeah so, and that's why I’ve always liked the idea that if you're getting errors from your application that maybe you're getting them emailed, or notified some other way. The goal is to get zero errors. You don't leave errors collecting in error logs without dealing with them because like you said in earlier, they could be hiding other more serious things underneath even if they themselves are not important.
Kai: Yeah … me.
Michael: And I guess one of the things that’s part of this is code complexity. Is that one of the things you look for when you?
Kai: Yeah, code complexity plays into the whole architecture of an application mind. And what you can say from a general point of view you know, language independence. If you have an over complex application, it usually leads to kind of an architecture situation where it's hard to understand what's going on. Unlike a higher level even. So you look at like an overall solution and you think like, mm-hmm, I have no idea what is happening here, and that can have different reasons. In ColdFusion for example what you see quite often with high complexity situations is it’s old code.
Someone has written an application in CF 10, 15 years ago, and it's in their typical spaghetti kind of [inaudible]. We have pretty much like individual pages that are kind of linked together and all the pages are doing their own thing. And some of them have logic embedded into the H.T.M.L. page, nothing is kind of split out into like different areas of concern. And the application itself, or what it's doing will not necessarily be complex. But the way how it's written, even a simple thing, leads to this whole cycle of dependencies and things going back and forth, and some logic in here, and some of the logic being done there. That's kind of like difficult to deal with.
Michael: And in the ideal case that the original developer through some global variables in that get randomly changed deep inside the code.
Kai: Yeah, the whole thing is like you find those problems in other technologies as well. I mean if developers do that, they can do those bad things in any language. So I do really know I also do a lot of [inaudible] [08:29] work nowadays. So I use Java and [inaudible] to build android apps. Sometimes, you see like crazy things in there. Just feel well and you would think like well, Java is a more formal language, and it is a static language, and like the community of Java developers is maybe more mature than the ColdFusion community in some ways. But it's not. If you want to use a language and technology, you can do in any language basically. That's just like one of those universal truths I think.
Michael: Yeah, I'd agree with that. Is one of the other things how the variables or functions are named? Is that another sign of code quality or?
Kai: Yeah there can be basically. If you have scenarios where you have a class or in ColdFusion maybe a CFC, and that has 200 functions. And they're all you know, I mean that may be well named. But if you have 200 functions in one kind of class, or component, then that points to that being a problem potentially as well.
Michael: But if they’re called A1, A2, A3 or some other silly naming. I’ve seen things like that is like you know.
Kai: Yeah, totally and that's clearly not good. A function should always be named and explain… in a way that it can easily explain by naming what it's doing; at least.
Kai: get something
Kai: Or you know save data in. X.M.L. we know whatever you want to come up with. But certainly not A1, A2, A3.
Michael: Yeah, and sometimes people go a bit crazy on the opposite end. They have a name that looks like you know, it's got 30 different verb pieces in it. Reminds me of retrying to read German many years ago.
Kai: German has a lot of long works, yeah.
Michael: Yeah, and nothing against the language. But if you're programming, and you have a function name that goes on off the side of the page, that's also not good for code quality.
Kai: Yeah, I find that quite a bit in testing in particular. There are people like unit test functions. Quite often, there is the tendency to come up with really long function names for those unit tests. Like Test, get data from database under the circumstance of A equals zero and strut is empty, and then you end up with function names that are super long. And that even if you use Kemel case, if you use underscores between the words, it's really, really hard to read.
Michael: Yeah, and that's maybe part of the basis of good code quality is the code easy to read, and understand.
Kai: Yeah, that is a fair comment I think. But that's a very individual judgment to make, right. Like what you might find it easy to read and understand I might say business still not good enough or vice versa. Or we might have totally different expectations about basic things like, how is code indented [inaudible] not always called … Do you put them at the end of the line, or do put them in the next line, right? And I mean developers are funny creatures. Like we are basically… we are very individual and each of us things the way how we do things is right.
Michael: And I think for you know, if you’re used to putting braces or whatever other feature in a certain way, you kind of when you read through the code, you're looking for them to be out of place. And if someone's formatted it differently, it kind of throws you off. So, I think there's a good reason for that.
Kai: I agree. You would look at code, you get that feeling this is not right. Even though the code might not have a problem, it's just you’re expectation for code that kind of a bit off.
Michael: Yeah, so let's have a talk about what tools are out there for managing and measuring code quality. Because we want something a bit more objective, and we want something that's automated that we can run through code work we’re maintaining.
Kai: So in an ideal world, you would have a whole lot of different tools, right. That starts with… It starts with analysis of your code. So you want to have something you can actually trigger either through UI, or through code online, or on a built server to one of the [inaudible] in there at maybe check-ins or something like that. That goes over your code and it gives you some sort of feedback. I mean a lot of people do those basic things with unit tests, right. Unit tests are kind of a way to measure code quality. Not in a neutral kind of like everyone agrees on way necessarily because unit tests are still written by developers.
When you write your own unit test, so if you want to have 100 percent success and you don't test you can write some really stupid unit tests and they will still pass, but it doesn't give you anything for the code quality. But the concept is the same. You basically want something in an automated way ideally. And when you look at code analysis, there are… the most common one is static analysis. So basically, you have your code sitting on a hard drive somewhere on your server, or on a development environment and you run a tool against that code base, that tool would not execute your code. It would actually just look at your code, and that's kind of where the term static code analysis comes from basically. It's not kind of a runtime analysis.
Michael: So it's looking for bad things in your code, or looking for syntax that's not correct, or.
Kai: Yeah, so that could be in its most basic form. It could be a compiler right that runs, or that complies your code, and that says yeah this code compiles or doesn't compile really basic, yeah. So you could in Adobe ColdFusion it’s like a compiler script in there. So you could just run that for example. Well, if you have an application where you initialize all your CFC’s into the application scope for example which is still a very common thing to do in ColdFusion. If you treat the application scope as like the storage unit, or the storage container for your CFC's.
You could run that part of your code, and basically pretty much by that compile all your CFC’s, and force them to be put into the application scope. And if that actually works, it doesn't throw an error, you know something about your code, right. You know that it's technically correct. And that's one of the problems that a lot of other languages don't have, right. For example coming back to Java, Android, Cotland for example. When I build an Android app, and I save from my file in Android studio. It will basically automatically give me feedback in the I.D.E.'s if this is correct or not.
Kai: Because it has all of that analysis built into any I.D.E.’s. And in ColdFusion, we have much weaker tools from a development point of view. IntelliJ has a ColdFusion plugin that has some of that. So in IntelliJ’s ColdFusion editor, they get some syntax problems and some kind of low level of limiting provided by them. Then Adobe has something with CF builder which in its latest version I think, and do some of that. But I'm not a CF builder [inaudible] [16:39] so it's a bit hard for me to comment on. But if you're using an editor like let's say sublime, or visual Studio code, sure, they have plugins for ColdFusion for syntax highlighting, and somewhat of a code completion. But they wouldn't give you deeper inspection of your code, right?
Kai: Other languages have that already built into their tooling which is a huge help. So to some extent, they rely less on tools further down the development chain because a lot of the things can be done right away when the code gets written. In ColdFusion, steady code analysis is particularly useful because we don't have that much deep inspection in a way that it does.
Michael: So as well as static analysis, what other kinds of ways of analyzing the code on are there?
Kai: So you could do kind of runtime analysis which goes into scenarios like code coverage for example. So you could actually have something that runs your code and then you would try to find out, is all a code that I have in my code base actually being executed? You know, are there any dead branches in my code? And never ever can be used, and if you have [inaudible] you might want to remove it from your code base potentially.
Michael: Now why would you want to know that code is not run? I mean you might want to remove it, but why else would you want to know it isn’t being run?
Kai: Because again comes back to complexity. If you have code in… If you have a file, say a couple of hundred lines, and half of that it's never ever been executed. I mean why do you want to keep that around in the first place?
Kai: I mean the other reason why that could be an issue is maybe it should be run and it’s not. So it could actually point of some issues in the code.
Michael: Yeah, it could be a bug that's causing it not to run, or it could be that your tests suite is not exercising that piece of the code which is a very common occurrence that you know, when people write tests, they often don't run every you know, you got an if statement and if else and the else never gets run in the test. So good to know which code is not being covered. And bugs tend to hide just like in the apartment with the cockroaches hiding in the dark corners. The bugs in code tend to hide out in piece of code that haven’t been run.
Kai: Yeah, I fully agree. And that's something I see quite often when we're dealing with clients code bases. You basically end up looking at something and ask them like why is this happening or not happening and no one can really tell you because it’s been written so long ago. It’s like, yeah oh, yeah that was that like eight years ago, or we have no idea anymore. The person who wrote that has left five years ago. Now it's like…
Michael: Right, another common reason I think is duplicate code. I don't know if you come across that much in your work but.
Kai: Yes, sometimes I do. You probably find that a lot within applications that do not have a framework, or where people move from legacy code towards some kind of a framework in a non-ideal way. You know where basically individual pages, individual templates just have duplicate stuff, you know?
Kai: And then let’s say them they make the move from there to use a framework. But maybe they copied those already duplicate bits into, or duplicate places in the framework which didn’t really help to alleviate the problem.
Michael: Right because then when you're maintaining, you don't know which piece of code you’re supposed to edit you know?
Kai: Yeah, I mean there are easy ways out for that right you could you know and then the most simple refactoring is find all the duplicate bits and move them into a ship CFC function, or something like that. I mean it's not even hard to fix necessarily. It’s just someone needs to take ownership of a problem like that and just do it [inaudible] [21:14].
Michael: So, what other areas do tools work on?
Kai: So, we had like a static and run time analysis. I mean another thing I really like for improving code quality are code reviews. Just basically taking that idea from … extreme programming which specifically pure programming or one part of it is pure programming. And taking that out of the actual development part, but you know look at it in a later stage. So even if you're… I mean for the people that know basically programming essentially means you’re not sitting in front of a computer alone by yourself, you're sitting there out with a PA. So two of you developers, or maybe a developer and a QA, or testing person sometimes if they’re close to code would work together on a problem for half a day, or a day on one machine.
So, you sit next to each other. One person is kind of driving and using the keyboard, and writing code. And the other person is kind of observing, and commenting, and basically making suggestions, or basically pointing out issues. And then after half an hour, or one hour, you swap roles. The other person will be driving and you know the original developer will actually moves into a commenting, and observing role. So if you take that concept to a point like where the code has been written, code review becomes kind of quite useful, right. Because you can do code review in kind of a paired way. So you could say right, so this code has been written by someone, let’s say me, and I would like to initiate a code review of that.
So I ask some of my teammates to have a look at that code, and their tools to kind of you know do that. Where you basically have a management tool for your code repository. And you would say, this commit, or this serious of change that so maybe you know these lines like hundred lines in your code or whatever, mark them in some way and then invite other people to review them. And that's a great way to improve your code quality because you get other developers of your team to explicitly look at your code, and to provide feedback. The important thing is with those kind of things, you need to provide feedback in a positive way or [inaudible] I mean that's the wrong way to express it.
What you really need to do is you need to conduct those code reviews in a positive way. You can't go in there and say like, well this is stupid, and wrong, and broken, forward all the way, we do it from scratch; as much as you would like to sometimes, right? But you're kind of need to focus on the positive things basically. And you need to kind of… you pretty much have to have a code of conduct for doing those code reviews. So the people who provide feedback have to do it in an expressive way, and the people who ask for feedback need to understand that some of the feedback they get potentially might hurt their professional feelings because you still need to be honest.
You need to be able to say like, “Well I don't like this because this causes these problems for that on the chain.” For example or this should be if you write of this way it would be ten times more effective, or faster. So you have to when you engage in those code reviews on either side, you have to kind of swallow a bit of your professional pride, and at least accept feedback. And then, in a worst case scenario say, “Alright, I disagree, I'm not implementing your feedback.” But you can't be angry about other people's feedback if it was given in a professional, and objective way.
Michael: And it’s basically taking your egos out of equation.
Kai: Yeah, pretty much, yeah.
Michael: So, which is always a good thing for writing code; not to have your ego involved.
Kai: And there are few tools that are really good for that. I use an open source code repository management tool called road code quite a bit. And that's particularly nice because it's platform independent from a repo point of view. So you can host Git, and [inaudible] [25:58] on it and people can write themselves. So if your clients were very particular about where their code lives so they don't like to be on the GitHub, for example, or bit bucket, they want to be in house and the …
So we use that tool in those instances and that has code review functionality built in. Another tool that is really good is a platform called Upsource from the Jetbrains. They are people who do intelliJ, and King city which is an automation built server and a whole bunch of other developer centric tools and Upsource basically hooks into your repository. You need [inaudible] [26:41] somewhere, then it allows you to initiate and manage those code reviews and correcting this over time and correct feedback from other people. So that's a very specific tool for that purpose.
Michael: And any of those tools also make it easy to tell which code has been code reviewed, or other pieces of code that haven't been reviewed.
Kai: Yeah exactly, and that would be in there. Road code wouldn't have that much of specific functionality into that. So in road code, you can’t easily say like you know, those 27 lines wouldn't have been reviewed because it's more a repository management tool that has kind of revenue functionality bolted on to it really. Yeah but other [inaudible]. I mean there's way more just like in the section of code review you probably fix five to ten really good tools out there that you could… depending on your platform and your requirements you know find to do that kind of thing.
Michael: There's also a company called Smart Bear that makes code review tools. I don't know if they work with ColdFusion, if actually they do so.
Kai: I’ve heard that name Smart Bear before. But I don't think I know any of the tools. Are not out of my head anyway.
Michael: I will check into those after the episode. But I'll put a link in the show notes for anyone intrigued by that. I met the founder of Smart Bear a few months back, and learned some things about it.
Michael: So what about the… I know there are a few other things you talked about on this as code correctness. So tell us about that.
Kai: Well, code correctness is essentially if you have a spec for your code which unfortunately a lot of people don’t. That you want to test your code basically behaves according to spec. And that's you know kind of the idea of the unit testing taking the bit movement to an abstract level. So you wouldn't really do that no level developer testing.
But you would essentially have you know, potentially a spec that is written in something as close to natural language. This function should [inaudible] ran this up in a script. This is another window should pop up; stuff like that. And there are a bunch of tools that allow you to write those specs, and they usually come from the Behavior Driven Development Movement – BDD. And then, those specs could be used to test if the code does what it's supposed to do.
Michael: And then what about complexity? Is there a way to measure that with some tools or?
Kai: There are a bunch of metrics for complexity in a code. And we actually… When Michael and I spoke before the episode, you pointed out there is a project of GitHub that I didn't know about that actually measures the … index for ColdFusion code from the mesa trends I think. So, I'm going to have a look into that. It seems to be it's a couple of years old. But it definitely looks interesting, and the link will be in the show notes. So I mean yeah there are metrics complexity apparently there is a tool for CFML that look at least to one of those metrics. With those metrics you always need to be a bit careful because that can easily throw you off as well. It's like a single number is not necessarily the best indicator of your code quality.
There’s much more play into that. But that kind of number can give you an indication. I mean as an example, my wife is doing a lot of work around stakeholder engagement in large organizations, and particularly around web content. And they use tools to measure readability of normal text, of written text for the web basically. And they have a bunch of amazing tools. I was just recently introduced to some of that basically. Where you [inaudible] [31:07] in your text, your blog post, or your article, or whatever. And it basically gives you a very simple figure like which grade in school would you need to be to understand this text?
And that's actually when you think about it, that's an amazing metric right. Because it’s like okay, you have to be in grade 24 in high school to understand this text which pretty much means like it's totally unreadable. Or … you have to be in grade eight, then you know if you publish it on the web maybe for like a tech audience, everyone should be able to read that ideally. And if we had something like that in programming, which would be cool, and some of those metrics try to do that. But you still have to be a bit careful because a number is a very, very thin thing to base your decisions on. I mean I think in code, a lot of additional things play into it. But it gives you a really good indication of how good, or how bad something might be.
Michael: Yeah, I mean maybe the thing to do is to get the number, the McCabe index, or complexity index and whatever. If it's bad, it would be good to justify why you wrote the code that way.
Michael: But if it's okay, you don't need to look into it any further.
Michael: And then the final thing on this that you wrote down ahead of time was cyclic dependency tell us what that is, and how that relates to quality.
Kai: Yeah, so if you have a system that comprises of individual parts. Let's say like modules, or if CFC’s, or classes, or packages. I mean it doesn't really matter on which level you look at that. What you ideally do not want a cyclic dependency is. You know that A depends on B, B depends on C, C depends on B again, and on a worst scenario, B depends on A. Because it basically means like you can't do couple of them. They are so tightly coupled. It's like dependency so that means like if you… to run A, you need B; to run B, you need A, and where do ready to start and that can cause a lot of issues.
For example: for object instantiation. If you have cycles in those dependency, it's like well, what do I create first if I need those ten objects? How do I set that up? And it becomes really messy. So ideally, you want to have dependency graphs that are not cyclic, that are that basically go in one direction for one of the top however you want to draw that. Because then your code is automatically less coupled. And loosely coupled code in general is preferable over strongly coupled code.
Michael: And then how do you generate a dependency graph? Is there a tool for that or?
Kai: There are a bunch of home grown tools. I've written a few specific ones for use cases for my clients. For example: if I got one client that have a lot of C.F.C.'s and we wanted to have a look at like, how do they all belong together? And what we were basically just doing is look at inheritance, specifications, look at the different ways, how they instantiate code inside of other C.F.C.'s basically. So you would say like okay, there's a great object statements. So you would pass the code, you were trying to find all the places when your code is spawn off, and then you basically generate a graph face of that.
And then, you discover like oh okay, there are all the cycles. And I mean after you have like a map of your dependencies, creating graphs is the easiest part because there are tons of really good like the open source graphing tools out there. If you have like a text file, and some format for example, it will draw a graph for you. And if you go with the right tools, it will tell you automatically if there are cycles, what the largest cycle is, what the smallest cycle is. And I mean there are tons of things that those tools give you if you have a map off you dependencies. So you have to create…
Michael: What’s your favorite tool for graphing these things?
Kai: It depends a bit on the use case. And then there are a bunch of Java, Python tools people have written that you can use for that. And I can put one or two links in the in the show note of stuff that is in general useful. But really everyone's requirements are so different, it's hard to say like this is the best thing. Because you know those command tools as well. They have to fit into your infrastructure. I mean you want to have something that ideally goes with other stuff you’re doing, or that you're running, anyway.
Michael: So, let's look at why there aren’t so many tools in the ColdFusion community for code quality.
Kai: You know that's a good question actually, or a good point. I think I mean for a start, there's effect actually. When you look at the list of tools you find for other languages, the ColdFusion community doesn't have a lot. And I think part of the reason is that historically, the ColdFusion community comes out of a community of people who just wanted to build a dynamic website back in the day. And it was never to… It was never as mature and as like professional as for example the Java community, or professional’s probably the wrong word. It's more formal. Formal is probably a better word. So ColdFusion developers do a professional job regardless if they use tools or not. It's just on a different level basically, alright. You can build a good ColdFusion application from a business point of view without using any of those tools.
That's the professional involved. But Java developers or people in the dot net world approach things maybe a bit more formal and a bit more from the point of view of building a large and potentially complex system. And I think historically, you probably find a lot of people in the ColdFusion community haven't been professionally trained computer scientists. If that makes sense. A lot of people who got into that platform came from like a different background, or they came from a business background and used ColdFusion to build something quickly, or they're self-taught web developers, or front enders who got into using a tech to do some back and work. I mean there are tons of reasons. And there are computer scientists in ColdFusion as well obviously, alright.
But I think the mixed in the ColdFusion seeing as a bit different than it is in Java, or in dot net land basically. And that certainly contributes to the lack of those tools. The other problem, and that's me blaming the [inaudible] [38:31] then is that starting from a layer back in the day over Macromedia, over Adobe have never shown interest in building in the first tools for the community. And if they’re… You know they should necessarily have to provide everything.
But it's kind of… like Adobe nowadays is more or less mainly interested in selling the server, and off you go, and you do whatever you want with it at the end of the day. And they're not really interested in providing a lot of tooling around that, and fostering kind of a more professional development practice. So a lot of that stuff has to come from the community. And some of it is basically. But the ColdFusion community is smaller than for example the Java, or dot net community let’s say, or the Ruby community. So you have less people interested in building tools, and there’s just less in the momentum essentially.
Michael: Well, and maybe conferences like C.F. Camp where you're going to be speaking in a few weeks are a place to have this kind of discussion. And certainly on the C.F. alive podcast you know, that's one of the things we look at how we make ColdFusion a modern successful language.
Kai: Yeah, and I think having better development tools is just one of those steps to make it a better platform. You know from a language point of view. I mean and I think it's easy to mix ColdFusion as a language of the product and stuff like that. I would probably want to call it like we could make CF, or CFML a better technology platform by doing that really for everyone and be no ideally [inaudible] [40:21] should be should be working with Lucee, and Adobe CF and the dragon, I’m not really sure about how active projects they are at least you…
Michael: No, not very active in. The main projects are Lucee and Adobe ColdFusion. So, what's the coolest tool you’ve seen in other languages Kai, you wish was available for ColdFusion?
Kai: I think I… Although the most useful tool probably would be a very comprehensive tool instead of in the US S. And the criteria to provide that or work on something like that and.Which is basically static analysis tool for CFM. But we are a very small group of people, we are very opinionated. So that kind of might not be the ideal tool for everyone but it's a start again for that as.—-
Michael: Well we'll talk more about that in a few minutes. But first, let's just have an overview of what tools are out there for ColdFusion code quality.
Kai: Yes, I mean one thing that is out there is like a Vasco part that was written years ago. And essentially, what it does is basically it runs over your code. It checks if you have any very by relations for locally scoped variables functions. So you know using the marquee sensor in the shell. But tool was written like a little long ago, probably more than ten years ago. And it had… its focus on your familiar tech code so once your script came out unlike all those modern changes to the C.FML language in recent here. The kind of got left behind and a few people have provided fixes for that but it never got accepted into the main C.F., into the main vast open project. So I think vast open nowadays has become quite stale and probably, it all solution. If you use vast open now would be to move to Seattle and because we've got vast open rules in there as well. The problem with Lascaux place it's also not using the proper pauser. So it's basically pausing your code where if regular expressions. And that you know in general not the greatest way to do it. Then another tool… oh sorry. I didn’t want to interrupt you. Another tool is CF— checker and we can have a look for the link and put it in to show not as well, and that's not a common problem but people write sequel code in C. very tax and they don't use CF— para to protect the sequel code from injections. And so, there is a checking tool for that. Again, I would probably say if you run that tool for that purpose, you should instead move to CF— and use the specific rules we provide in CF— for that you employ that because that will just give you a whole bunch of additional function do you want us.
Michael: And tell us a little bit about C.F. lent what it.
Kai: Yes, CF— if lint basically came out of the CF the project so.
I called right it will leave the press and he started simple and asked if pas and see a flag and see if part of us basically faced the A from alcohols are an endless kind of a compiler generation to a very well known in the job board a compiler or posit generator and so he used to be passed out out into a problem tree structure to a problem of the structure and then see if Linda's kind of an off spawn of that using that passed C F M L code to actually run checking wills against. And so if parlance here Flint up both not brand new There have been a wrongful like three four years that I thought. And I got kind of involved with the inflamed at some stage last year for the first time to a sixteen because I started using it and I found a few issues or a few problems in my own code or a client's code that were false positives. Or things that in a civil and at the time couldn't check so I started you know providing feedback and you know change requests and lockbox and then cannot you know stuck around and started to do things basically.
So see if limited use a see if PASOK their individual projects but they're kind of like to run see if then you need to have a version of the if posible compiled one bet into your code and if you only want to run see if you and that's perfectly fine you know you would never know the other thing in the background but it has to individual bits and Zealand comes as a command line tool you're basically saying hey this is the code I want to check and then by default it runs like a whole lot of rules and you can obviously say I want to run just a few of those rules or all of them or I want to exclude certain rules in certain directories and then it kind of Texaco.
And water and it gives you some feedback on where you have problems or Yeah so basically it will provide results.
Or it can provide results in various opera formats we have an H.T.M.L. output so it gives you might not pretty it gives you a workable web page basically with all the results and the result would be basically it would give you the final game of the violator group the line number and in some instances the column number and it would give you a line of the code for problem basically and you'll see it quite quickly or you get a feeling for quite quickly what to look for you know it's the. If you have us your very pair on the violation.
We give you the see if Cleary. Line in confusion code so you have to look into the query and you know find yourself where the problem is potentially but that's kind of all works so if you Mehlis what I'll perform at the other will perform it as we have an internal C.F. limit X.M.L. format that you can just go with and do whatever you like worth we've got a decent output risk if you take an object and support find.
A quiet technology universal stand out coming from the job world find a box of Java to essentially it's kind of a coat and Ellis the.
Results tool that vet exists for jar of net for tons of platforms and you can import it into Version control so and do all the. Chrome and what exciting things you're looking to add to C.F. Len this year so we've got actually a bit of a roadmap so we have currently released one doc true that was done a few weeks ago and we had a few bucks six witnesses since then so we've got now one of two one one two two or something like that. One of three will be the next miner release that's coming out and for that we're going to.
Have to make any mess of changes the changes will be working through a bunch of tickets and making a few smaller preparations for bigger work coming in to Toronto and to do that over basically future and Euro put generator because currently there are various open formats are done internally and a lot of different ways you know the it's a mellow approach is created one way the Find box except Melo produce credit in different way and I want to be unify all of that basically and have one output component actually minute. Is that all my so why. They are improving the code quality of C.F. lent itself yeah funny enough actually that's actually were there specifically we.
Should explain that as well as you have Linda's written in Java currently so it's not written in confusion as if. So we're writing this in Java or code and because a whole bunch of people have contributed over the years as it happens with but projects like that you know people do things in a different way and reap decided for.
Me unify some of those things and streamline some of the code.
The other thing we're doing two point zero is working or doing more work towards an A.P.I..
And the idea of that is we want to make C. of what X. more accessible for people who build tools.
No I want to basically be enable C.F. limb to be used in I.D.E.'s ideally so because right now it's a command line tool and a lot of the the logic and the way how was also created a bit in the year two what's command line so you would run it against your co-pays or you would run automatically if you want to but what we ideally would want to have some sort of an integration point where I.D.E.O. author or plugin author could say I want to run C.F. Lim kind of as a background process for example in your ID.
With your type I want my code to B.C. have lent it for that file or for that content and to do that we need to change a bunch of things what's the appeal and handling.
Stuff internally to provide those kind of flex years limit if you I point and we're not talking about the rest if you are a minute or people of July if you are the other people can use US Currently it really only has to come online in P.R..
And. Could that also mean that you you could call it in their continuous integration scripts so that when you can get a code you can do that now you can do that already basically and that's the call of is it basically because it's a command line as a mr can run something like a Windows command prompt or like a Unix bash or MEK bash or something like that into get together with your with your gracious of your fine and you know most of the questions I want to know can do that. And then does it give some kind of return code telling you the quality of the code or what it gives you I mean let it gives you inspection results that's what is usually cauterized So for example in team city that's the integration so I use quite a bit for for clients.
If you would run Z. or Flint as fine box as a Find box report because Jim said he supports that format so that's the easiest thing to do run it and give limp or create a results file in Find box external and then that results file a medical gets picked up by a team city and it shows it on the built report for that particular build as code inspections and then based on band you could.
You could make decisions if it's a local right if this any number of code inspections larger than zero I fail to build because I want to.
Stiffle in to report nothing if it darts then you know my build is not OK that's one way of looking at it. The other thing that you could do is you could say well I might have a whole bunch of problems in my code right now and I know about that but say if I run C. of learned I get hundred inspection results right now and some of them are things I know I want to change at some point but I just can't do that now. You can team city in a way that it's alright if the number of inspections found in a certain branch of your apostle tarring.
Increases then we fail to build So if you have branches a but a few chop and you had hundred code inspections you produce new ones by writing you know code that fails the Evelyn tests it will fail the built but as long as your code inspection stay at hand wrote it will pass the built.
In a point like Consider for instance can crack that by barrage So another branch before it's off could have two hundred fifty code inspections right now and the room could be if that increases a fail the build if it stays hundred fifty I passed.
So you can look at the growth in the badness of the code if you get yes me too smelly then you rejected it or you could you know you could actually even make it a percentage rule you could say like if the number of inspections increases by more than five percent we failed them or something.
Sounds really interesting. How do people get hold of C.F. Lent is when there is a get up repository which would be in the show and you can do different things on the guitar propose authority as a release pager release of release as page and you can to stun load a zip file that's the easiest way to get going that's the file that will contain a jar and you run the Jar Jar welcome online job our minds jump and then you know specify some come on time permit us we also have a quite big Whitney file on the guitar page or the start page of the get a proposal Tori's actually written a file that is.
Some contain some basic documentation that has examples how to run it how to include an executed rules and how to just. It going in the most simple sway.
There used to be a Wiki but we found that the bikie became stale over time and we find it's actually a better way to provide documentation as part of the repository because then you know when you release a new version you up there the documentation and the documentation actually matches your tool at any time and it not like an old wiki page from two years ago that has nothing to do with the two works anymore so we changed that recently so the documentation is currently really up today.
And you know we are actually quite friendly bunch of people we have a code of conduct in our project we try to be you know nice to people and they need help and we expect people to be nice to us when they ask for help and that you know kind of seems to be working so far.
An open source code of conduct Yeah I would recommend that for before any open source product really because it sets the tone a little bit.
And I find that you know useful nowadays basically I think that's useful in any community yes and I used the code of conduct of a conference here in New Zealand as a starting point now Rotha.
The conference is called Web stockings one of the nicest friendliest where conferences I've written much ever been to.
Their code of conduct is pretty much like you know it comes down to don't be a dick.
And that's that I mean ideally that's all you need try and but then I basically extended it a bit and try to explain what we are what we want to do and what we expect and how people you know how we expect people to behave and how to you know like out. If they feel violated or threatened or uncomfortable that's. What to do about it so yeah and I think I think it's really important I've been involved in writing several of those kind of documents I was involved in one intentional community and then I've just helped out a lot from the community with their community guidelines which is similar concept have a look at the sea of law and code of conduct if yeah I'm totally keen on any feedback to improve it and make it better Basically if you can think yeah happy to look at it so anything else I'm seeing flint you want to share with us now that is probably. Good for now make sure you come to my talk if you're at C.F. camp to actually see it in action and get a few more technical examples of you know how you set up stuff and also going to be showing how to compile and how to contribute to it or at least do some basic contributions for Star fabulous and then other any other tools that help with code quality like documentation mill there are bunch of documentation tool something there is some called doc that Mark Mondale wrote.
Ages ago together when you had the cold spring library probably.
But that's not being maintained a lot anymore.
But all those guys have. Done the documentation cool cause docs thing which I haven't played with myself yet but that looks I mean you know we know that when it comes out of office it's usually a could go to. So that would be worthwhile looking at. That is well all those documentation tools cover a very certain aspect of you know code quality so on the I become our documentation quality or they come of the fact that you want to have to commit Taishan in your code if you can use to create something that can be read outside of your car and the interesting bit about that is.
It changes the way how you write documentation.
But not experience because if you know that
what you write in your code is documentation gets extracted and formatted in some other are in some other output you automatically spend more effort on documentation I like to think or that's my experience from teams at least and that's a good thing so even if you're in a realistic if you never want to look at the documentation again it's extracted format just basically creating it usually improve the standard of the documentation you get from people write because they know it's going to be looked for yet.
So what are the other any other things to help out with code quality you. That's pretty much it I mean your people individual people have probably written their own little tools to do certain things like you know I've done with it cyclic analysis for some climbs or you know you look at very specific use cases like trying to find.
You know if certain tax are used in a certain way but most mostly I find people don't make those little tools public in available I know that exist. Or little Beano deployment scripts or other checking tools and they exist usually behind fire walls or in internal culture puzzle tarries or in you know in on individual developers hard drives in a temp directory and ashamed that a lot of those things in the never see the light off public because I always like to think like any tool is better than no tool even if it's written in twenty minutes at the site and there's always someone who can make use of something and improve it and use it for their own you know their own benefit so I would a lot of people make those little things more accessible and more available but it's kind of a heart.
To Heart thing to break into you know it's hard to convince people that's what we're doing that for might well would you be open to people sending you their secret to check out you know if I'd be maybe to put them all into a repository or get up if people have no idea how to use guitar and don't know about open source coding and you know what to do with that if anyone sends me something I'm more than happy to put it in the Get Up repository and credit them I'd really don't care about you know my ownership off of that it's like.
I just want to get it out there that people can do stuff. OK so I hope everyone listening you've got secret code quality tools hiding in there so that they can just send them to come back like yeah he'll help get them out into you know depending on what it is we might be able to include the idea at least into see if Lim I mean there are tons of ways how of where you can create synergies between those existing things and stuff that we're doing anyway and.
I think from a technology point of view confusion has its place wide it's a good technology for certain use cases when you want to build a petition really quickly you need to get going you want to have built something that is that can be you know what it is the released rapidly and is still maintainable. And that integrates with other Java technologies for example so for me it's more about finding what could be mis case for C.F. or Lucy as a technology platform. But at the same time in a lot of cases you know by computer doesn't that from my point of view doesn't that why the device I mean the most typical example is here for mobile and you know the thing that Adobe released a while ago that you can build a mobile app out of.
A lot of confusion second code this is just a terrible idea it was a terrible idea from the get go and it's still a terrible idea and no one's using it and everyone told Adobe So you know when you look at that it's like you need to find the right tool for the job and just because cold fusion can do one thing or something's really good it doesn't mean it should be used for everything.
So coming back to the question I'm not pro to use cold fusion I'm I think fusion is a really good technology for certain use cases and you need to basically use it in the white instance you know like that's that's probably you know the best answer on that race so you know I know some people of said in years past the cold fusion was dying and I think that's not the case but my question to you Guy is what would it take to make cold fusion more lives this year.
I think. Or there are so many things you could do to be honest right when we talk about some of them already I'd like I'd like have been a developer tools to. One thing the other thing in this culture. Is in a difficult position from a market point of view because it's a rep to well of and platform that Adobe wants a lot of money for and people don't really understand why that is for good reason five because a I want to build a weapon I can use note or rails or even jump out of net or whatever and I don't have to pay anything. So if Adobe would want confusion to be more widespread the first thing would be they have to release a free or ideally open source version that basically cuts off that Haute enterprise stuff that's in there like you know forms and maybe you know the S.M.S. messaging gateway and all that stuff that to build a normal by Papua really don't need that and just make it a whale at the same time.
Or in this in the direction it would be awesome if Lucy would get more publicity more and because I mean they have a really good.
Source if Mel So that is in a lot of ways better than a dog because you can you know perform one of you for instance and also in some ways from a language point of view.
Then surely Lucy gets some traction but you know it should be ten fold larger ideally by now right from a community point of view and from a usage point of being.
And it's a perception problem because people perceive confusion and see it from L. as a dying thing I've So we're basically stuck in a chicken in a chicken actually who is right and here.
To be fair though Adobe has been trying to do certain things that have that university curriculum side affair is however that it's extremely impossible to you know to get to that and to get in the first place and then used. I need to quote Fusion which is a commercial product you can fill in our education licenses so it's kind of like a lot of it revolves spectacle fusion costing quite a lot of money for someone who wants to build a website because they can do that for free and you know as fast as inculturation in ten other technologies nowadays so that's a big issue.
I said on Twitter a while ago you know in a deal world order this should be called Fusion from Adobe because they are actually driving a lot of the innovation in this year from a community and you can't if you're a C.F. developer or C.M.L. developer.
You should definitely have a look at at least some of the box to even if you have a coach box person which is totally fair now have a look at the tools around cold box no test box and walk box stock box there so not come on Bob you know come on a come on box to mention had or you know they have a tool for configuration now and there are so many things they those guys are doing which are really really great right and it's awesome to see that innovation coming form from a search party company but you know given the lack of innovation coming out of adobe and why is a lot of you know all this could just buy confusion and run with it and we would have a much better product I think maybe they could go even further and just by Adobe.
Yes maybe of the two a vicious fun now or but they're in the long run now it's.
Great so you're going to be speaking at C.F. camp What are you looking forward to add it.
Up until things you know for me it's kind of a bit of a family homecoming meeting to be honest I mean the talks obviously interesting but I really enjoy it as an opportunity to meet. Well friends from the European C.F. community your cinema community which I didn't get to see that often basically in. Camp has become one of the conferences I plan to go to really only in the year so as soon as it comes to kind of you know February March I usually. Try to secretly get the date out of.
Michele and plan my trip in advance to make sure that I can actually make the dates and what is actually kind of nice as it's usually not far away from another conference I want to go to in long which is quite common U.K. So this year this is the week after C.F. cam so I can just you know go to Europe once and go to see if Cam and hang out a few days and then go to London to go to com and continues on. And I think to one go and I noticed you're learning how to fly around small plane a are you going to fly yourself to C.F. camp one year of there will be lawfully and.
No that's probably never going to happen so I mean yeah I've got a pilot's license for private use like a P.P.L..
But it's for light single engine and like twins I know I would already struggle making it to Australia basically people have done many people have crossed the attachment see to Australia are with light aircraft but usually all Slike. Island hopping so you would go from the left to one island then to another island then to Australia it's like a two or three day trip and it's actually even if you do that it's kind of dangerous because if you think that there's a single combustion engine him and you're flying over are an ocean for like five or six hours each leg it's kind of like get on the chair if I want to do that basically yeah but once you get to Australia you can just hop over in an easier and just fly over a sherry and be. In Germany before you know it you aren't you trying to get people to do those were traps right but when you actually read the books of the trip and.
You know it takes them probably three months to do that.
But it's kind of like yeah not really realistic to do that I think. OK Well thanks for being on the podcast today cause i Thanks for having me it was really cool awesome.