iPhreaks

The iPhreaks Show is a weekly group discussion about iOS development and related technology by development veterans. We discuss Apple, tools, practices, and code.

Subscribe

Get episodes automatically

168

iPS 168 Automated Code Metrics with Simone Civetta


DevOps Remote Conference

NoSQL Remote Conference

1:50 – Introducing Simone Civetta

Twitter

Blog

Frenchkit Twitter

2:16 – Automated Code Metrics in Swift

4:06 – Strategies to Determine Code Complexity

6:17- Adding a Language

7:28 – Why Is Cyclomatic Complexity Important? How Can We Use This Information To Improve Our Code?

11:02- Difference Between Cyclomatic Complexity and End Path Complexity

13:40 – Using and Understanding Different Values of Cyclomatic Complexity

15:10 – Automating The Process

16:38 – Integrating Metrics Into A Complete Dashboard

18:12- Technical Debt Metric

21:16 – Stressing About Metric Values

25:50- Impact Of The Community on Swift’s Tools

  • SwiftLane
  • Carthage
  • Tailor

27:55- First Steps To Evaluating Code

30:15- Using Code Climate

31:20 – Using Hound

33:30- French Kit Conference

Picks:

Slide Deck Link (Jaim)

The Hero of Ages: Book Three of Mistborn by Brandon Sanderson (Layne)

Wood Badge Scout Training (Charles)

Boy Scouts of America (Charles)

Postal (Simone)

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Charles: Hey everybody, welcome to Episode 168 of the iPhreaks show. This week on our panel, we have Jaim Zuber.

Jaim: Hello, from Minneapolis.

Charles: Layne Moseley.

Layne: Hello from Utah.

Charles: I’m Charles Max Wood from devchat.tv. A quick shout out, about a couple of conferences we’ve got coming up toward the end of the year. We have DevOps Remote Comp, I’ve got a couple of web development ones in the middle, but then we also have No Sequel Remote Comp. If you’re interested in those, go check them out.

We have a special guest this week and that’s Simone Chiveta.

Simone: Hello everybody.

Charles: You want to introduce yourself?

Simone: Yeah, of course. I’m a developer from Italy, I’m actually based in France today. I’m mainly doing project work and I’ve been working for the last couple of years for Louis Vuitton making business and private apps.

Charles: What we brought you on today to talk about is automated code metrics in swift. Do you want to give us just a really brief introduction to that, what you mean by automated code metrics?

Simone: Yeah, of course. Automatic Code Metrics in Swift especially are a way to gather most of the information about your code, the way you code, the mistakes you’ve done and to collect them in a dashboard and read them periodically to have a clear idea of where you’re at with your code.

Charles: I think I’ve used tools that do this kind of thing in Ruby. I haven’t set any up on any of my projects in Swift or Objective C but I think the idea is that they check things like cyclomatic complexity or test coverage or things like that. Are those the kinds of metrics you’re looking at?

Simone: Yeah, sure. We are basically targeting a code coverage today called complexity, duplications. We also can have other information like depths of inheritance, non-commented source line statements, other code issues like the issues you will probably get from LinkedIn process.

Charles: Very cool. The automatic part is just running it in continuous integration?

Simone: Yeah, totally. You can run it through fast lane. It’s actually my favorite way of running them. My fast lane is plugged into my Jenkins and so it actually performs checks every night. Also, you can do it manually if you prefer. Since it’s kind of a long process and you don’t want to embed your time which is already quite long thanks to Swift, you’d probably want to do that in a continuous system.

Charles: When you say code complexity, I’m really curious about the exact strategies you use to determine code complexity or if you know much about that.

Simone: There are two kinds of code complexity I’m kind of interested in. One is cyclomatic complexity, and the other one is end path complexity. Today’s tools in Swift only support cyclomatic complexity. They basically count the number of branches your code has. It basically counts the if, the switches, and so forth. This is kind of cool because you get a number for each function you have or each class you have. That number basically doesn’t say anything at first but after a while you understand that it’s kind of really connected to the difficulty you have to understand of a given class or a given function.

Another thing is that in Swift today, the tool you use is called Lizard, it’s a small Python script that reads all your code and understands where branches. It’s not the only one, we can also use a Swift link although Lizard gives you full calculation of all your classes on your functions and not only those who couldn’t pass the given threshold.

Charles: If it’s written in Python, does it have some way of recognizing those branches in Swift? Because the syntax isn’t going to be the same.

Simone: It supports a wide range of languages, it doesn’t support Swift only. It supports Java, C++, and so forth. It’s basically a code browser. You give it the code and kind of understands how the code branches, basically.

Charles: Yeah, that makes sense. It has support for multiple languages. If I wanted to add a language to it, say PHP or Ruby or something, there’s an easy way to do that?

Simone: Ruby is already supported although there’s bugs. JavaScript is supported as well. But if you go onto languages that don’t exist today or other languages that aren’t supported like Haskell for example. You just have to provide Lizard with a reader which actually is basically a list of keywords who compose your languages. That’s basically all.

For example, the language browser for Java is forty lines. First, we have to use 6070. It’s quite easy.

Charles: The process itself seems like it’s fairly straightforward if you want to do it and try a new language, just add some text.

Simone: Super easy.

Charles: Determining if statements, which statements.

We talk about cyclomatic complexity, that’s the number of if statements or which statements that are within a function or a class. Why is that important? How do we use this information to make our code better?

Simone: I can provide two examples which is actually taken from my direct experience. The first one is—I do project work. I sometime go into a project and code myself from scratch. I actually have no idea of how the code is, I should really read through all the classes, all the functions. At first, I have no idea of the complexity of the difficulty I will have into understanding what the code does.

The first thing I could do in such case is to have a rapid scan through the cyclomatic complexity analyzer like Lizard. I will understand in a few moments which are the most important or also the hardest classes to understand. In a given project I guess like 5% of the classes is not really well coded or it’s too hard to understand. Cyclomatic complexity gives you that idea in a few moments so you can speed all the classes you don’t care about and just get into the point and read the one, two, or ten elements which will take you much time to decipher.

Charles: One thing that I’ve seen with cyclomatic complexity is that longer methods tend to have a higher cyclomatic complexity score. The reason is because there’s a lot more going on in there so it creates more branches that you can follow throughout the code. If you have to hold all of what everything is going on in your head to understand that method, then there’s a lot more to keep track of there. Usually, you can solve this by breaking some of it up into new classes or new methods and setting things up so that they call into each other. That way, you have a much smaller, less complex part of the code that you’re going to actually execute to get work done.

Simone: Totally. Actually, most of the times code is not hard by itself especially mobile apps. It actually gets harder when the developer doesn’t separate the methods of how they should be, he doesn’t extract them. The whole complex thing is about you not being able to understand what the code does. The longer method it is, the harder it is for your mind to keep track of what is actually going on.

Complexities is actually quite good for that. This was the first example and another example is through day to day work. I don’t really like to set up a dashboard for that so we can call it evolution of the code base throughout the weeks and days. It gets almost like a game. You compete with your fellow programmers and you see who scored better, who actually created the method in which your code complexity scores are really bad number. It’s kind of useful for that.

Charles: What’s the difference between cyclomatic complexity and end path complexity?

Simone: End path complexity is basically an exponential value. This is because for each statement, cyclomatic complexity actually counts basically if it’s a branch statement and that’s nothing much. The end path complexity counts all the possible branches and all the possible path your application can actually go through when it comes to your code.

Let’s say you have three nested statements, three nested ifs for example, the cyclomatic complexity says this is cyclomatic three, whereas the end path complexity can give you a number of around eight for instance. From my own experience, I’ve seen codes in which we had an end path complexity of 200,000 that was massive and actually allowed us to say okay, this code is trapped here. People take much time to understand it and to refactor that.

Charles: So end path is over the entire code base or the entire class? I’m not sure I still understand that.

Simone: Cyclomatic complexity and end path complexity are actually about code blocks. They can work and both work for a function or for a class, for a package that’s nothing which changes between end path and cyclomatic complexity for that. It’s actually about how the branch affects your count. For a cyclomatic complexity, of course every if, every switch counts as one. Whereas for end path complexity, it’s not the presence of our if or not which counts, actually how many branches you have.

Jaim: It sounds like end path can get huge very quickly, it sounds exponential.

Simone: Totally. It gets huge very quickly especially if you have a really deep code. For example if you have in the mid of doom, the cyclomatic complexity may or may not be high value. Whereas quite often end path complexity is really high in those cases.

Charles: With these different values, how do you use the different values? What values of cyclomatic complexity or end path are warnings or what are too high? How do you use the values once you get them?

Simone: Basically, used for refactoring purposes. To understand which methods need to be able to work. We generally know that an end path complexity and a high end path complexity as it was said before is a synonym for deeply [00:14:07] code. This is code which can be almost immediately refactored by extracting methods.

When you have high cyclomatic complexity, it means the math is too long or the class is too long and you have too many lines. It’s similar inside but with different nuances. Still, it’s a good value for determining your technical debt. It gives you an idea of what your work should be focused on when you’re doing refactoring.

Charles: That makes sense. Do you have ideas like what numbers you should start to be worried about and which ones you should definitely start refactoring?

Simone: Yes. For cyclomatic complexity, we generally say about ten or fifteen. The end path complexity, we generally say about 80, something like that.

Charles: When you automate this, do you set up some kind of alert that says hey, you’re too complex, or do you just check on it periodically and see where you’re at?

Simone: When the cyclomatic complexity or the end path complexity are above a certain threshold, we generally show a warning in our panel. Swift does that if the cyclomatic complexities were passed at a certain value, in that case a warning will be shown or in some cases even an error. The application stops compiling.

Jaim: Can you integrate that with Gab and have a little badge?

Simone: Yes and no. If you was in Swift, you can. Swift actually generates a warning which is compatible. Those warnings can be integrated quite easily into GitHub with services like SAAS services. You can easily have your yellow red lines in your GitHub.

Lizard doesn’t do that, Lizard actually gives you a full report. You should maybe integrate that with other tools like [Solar Chip].

Charles: Lizard, does it give a report based on functions? Like it will lift all your functions and show you what the numbers are per function or something like that?

Simone: Totally. My talk was also about how to integrate all those metrics into a more complete dashboard. It’s another direction we can go through.

Layne: Let’s talk about that. Let’s talk about how we integrate this and other tools so we can get feedback on the state of our code base. What’s changing? What do you recommend?

Simone: One of the tools we have in place is [Solar Chip] as I was saying before. [SonarQube] basically is a hub for different metrics. Of course, it deals with cyclomatic complexity and duplications and code coverage. It creates sort of dashboard which contains all those metrics and can show you for each class you have where the issues are.

It also computes a technical debt value which is average number of days you should spend on refactoring given code. What’s nice is it’s kind of visual, you can build a nice chart with that. It’s kind of well suited for continuous integration screen at your workplace. Also, that was for searching through the various metrics and doing composite searches and comparing differing values of different metrics to better understand the quality of your code.

Charles: I’m curious about the technical debt metric, I’ve never heard it expressed in a unit of days, how many days per week or whatever. How does that work?

Simone: I wasn’t familiar with it before joining my company. It’s actually a Java company, it was founded by old time Java developers. They all had that notion of technical debt which I wasn’t familiar with is actually a number of minutes which is associated with each kind of metric, of course just an estimation. Each value gives you a number of hours, minutes, or days which you’ll spend on refactoring that. At the end of your analysis, you have a sum of all those minutes which can build up into days of working for resolving all the issues.

For instance if you have Swift, you can have issues like [00:19:18] by white space and the correction takes five seconds. If I have thousands of those corrections to do, it multiplies of course the number of seconds needed for a period. It gives you an estimate of technical debt.

Jaim: Have you tested that metric and does it seem pretty accurate?

Simone: No, it’s not accurate at all.

Jaim: Okay. That’s what I was wondering because everyone works in a different phase. It just seems like that would be kind of far fetched.

Charles: One other metric that I’ve seen that is kind of non-sensical but useful at the same time is in agile you have your velocity. It goes up and down as people are more or less productive, you have somebody out of town for the week, whatever. But the thing is that relative to the number last week and the week before and the week before, I can tell you that we’re doing better or worse.

Jaim: That makes sense.

Charles: If you have some number related to technical debt, no matter how accurate it is as far as this is how many days per week you should spend working on this stuff. If my number is going down as we steadily work, then I know that we’re making progress. If it’s going up, then I know that we probably have some practices that we need to change because as we write more code, we write more technical debt into it.

Layne: Right.

Jaim: I have no idea where we are, but we’re getting better.

Layne: Isn’t that what you think is a software developer all the time?

Jaim: You hope so.

Charles: I do have these moments of clarity and then I figure out that they’re total crap. It’s like oh yeah, we’ve arrived, never mind.

Jaim: With all these metrics, these numbers we can put on a screen that tell us to refactor our code, this can lead to the anti-pattern where you’re just making refactorings to get to this number where we want it. You got some architects looking at your dashboards saying your CCN needs to be below four and you just make some brain dead refactor that just gets the CCN to where someone else wanted it. How do you avoid doing that?

Simone: I try not to stress too much about metrics values. As somebody of humor was saying before, sometimes it’s just nonsensical. It’s just numbers and they sometimes have no relation with the actual status of your code. Sometimes, it’s just not important because if you have wrong parenthesis, sometimes it doesn’t mean you’re a bad architect or your application is hard to maintain just because you decide the Swift guy is not respected.

What actually does instead is to curate sort of a team goal for the long term. You know where your goal’s at, it doesn’t mean you actually have to get it 100% but it keeps you focused. Sometimes it can be fun to see how people code and how all your colleagues work, we all work differently. It basically creates kind of a team collision in which everybody has the same goal that’s going to be kind of good since with four or five people.

Charles: The other thing is I think a lot of times we’ll get somebody who used some of these tools in the past job so they have this idea that in that code base we’re able to get 99% code coverage which is another automated tool that I’m pretty sure you have in your dock. But at the same time, this particular set of code for whatever reason just doesn’t play along that way that well.

You have to look at it and really try and figure out what are we trying to do here. What are we measuring? What are the implications of keeping track of these numbers and are there any better ways of knowing that we’re getting where we want to go? I think that’s kind of the idea that you’re trying to put forward is that you don’t always know that, you don’t always know the answers to some of those questions.

Sometimes, you know where you want to wind up and you know what the code should look like but you’re not really sure how to measure that. You pick something that gets you part of the way there, you set up your dashboard so that it gives you the information you think you want and then you can slowly move ahead from there to figure out what if we take this number and we change the way we look at it slightly, or what if we measure something else and put that into the overall equation of how are we doing and then you start to make real progress. But yeah, the numbers for numbers sake is definitely a dangerous road.

Simone: Most of the time, those tools can counter place your confidence. You can have really good notes on that but still it doesn’t mean you’re a good developer or your code is perfect, actually. It doesn’t mean much of that. Actually, today of course maybe it’s the best part of our job is that nobody can replace your confidence as a developer, your experience, your vision, your reads. That doesn’t help much. It’s good to have it to have a shared goal as I said before, but it doesn’t make you worse or a better developer.

Jaim: There’s lots of times when I’ll write code and I know it’s bad. I’m okay with it because I know it might get thrown away or there’s some purpose behind that. It does seem like a tool like this can help you in most situations where you had to rush through something or things didn’t quite go as planned and then you have time to go back and make it better.

Layne: When did this ever happen?

Jaim: That is also a good question, maybe it doesn’t. That’s more of a rhetorical.

Simone: What I like on Swift today is that before, especially with [00:25:28] doing all this metrics stuff was such a pain in the ass process. It sometimes didn’t, so you just spent much time trying to fix tools and then you spent half a day fixing a given tool and not refactoring. That was completely crazy and useless.

What’s fun with Swift is that it’s not only a language with good new features but also it was the occasion for the community to reinvent the tools and to make better instruments. Today, setting up metrics for a certain project is like 10,000 times faster than it was. That 10,000 is personal metric.

Charles: I’m wondering though, is that because Swift is built in such a way that it enables that or is that because the community is that much further ahead now in understanding how these tools should work?

Simone: No, I guess it’s not only because of the community’s language, I’d say even not at all. Actually, it’s because all of a sudden realized that there are still lots of stuff to do. Many people in the community tend to think what if we had lanes of Swift, so they built a Swift Lane. What if we can have a proper handling of code coverage, it’s what Apple did and what Slather does as well.

Layne: I saw your talk at [00:27:09] this year, 2016. Based on where Swift was the year before, I was completely blown away by how much the community had rallied around tools like this. I was pretty impressed.

Simone: Yeah, it moves really, really fast. I love tooling aside from metrics, there is lots of stuff which has been done in just two years. You can think about Carthage, SwiftLink, there is a Swift Link competitor which is called Tailor which almost does the same thing. There are lots of services out there which already support swift. I’ve got support Swift since the very first days. There’s much hype, it’s a good type around the language. That’s just positive.

Charles: If somebody decides okay, I really want to see what these numbers are for my project. I think they’ll help me evaluate the code and know if we’re moving in the right direction. Where do you suggest they start? Are there particular metrics they should start plugging in and should they set them up on some kind of automated system to that they can see them or are there other better ways of doing this kind of thing just to get going so that people have the information about their code and code quality?

Simone: The very first thing we can do as beginners is to start with what Apple offers. The first value for that is code coverage. Code coverage since last year is supported by each code out of the box. It was also supported before but it was an old format which  was [00:28:50]. It was hard to exploit and to read. Nowadays, it’s much easier. What’s funny is that code coverage provided by Ace Code is also supported by the xcode bot and the xcode server. With almost no experience, you can set up your building machine with an Ace Code server and already understand how your code is covered of course if you do tests.

Another thing which is really straightforward to apply is Fifth Link once again because Fifth Link can be added as a built step and provides as x-code compatible information. That information is just like the claimed one or this [00:29:41] is basically quite simple to interrogate that into your xcode build steps and have your lines be highlighted if something is no good. What’s great with that is that it’s also supported at all the bugs with no hacks, with the xcode bots. That’s quite easy and with that you can get at least cyclomatic complexities threshold as well as a basic side guide checking and of course code cover.

Jaim: Have we talked about Code Climate yet? I don’t think we’ve mentioned it. Anyway, I had to use Code Climate in the past. It looks like they’ve made some pretty good progress, they have a free command line interface tool that you can use. That’s pretty cool.

Charles: Is Cold Climate available for Swift? I haven’t looked at it recently.

Jaim: It looks like it is, yeah.

Simone: Actually yes, it supports Swift and also supports—it really supports Swift in a way because you can go through Slather which is another tool I haven’t talked about which is basically a converter from any kind of xcode code coverage information like Jacob or the proof data which is the newest one and can convert that into almost anything else. Let’s say you can convert to [00:31:13] which is an XML format or Code Climate format.

Charles: What other tools are we missing?

Simone: There’s Hound. Hound is another service just like Code Climate. Hound, I guess Ruby’s already used that for checking style guides.

Charles: Yeah, Hound’s been around for a while. I’ve emailed back and forth with those folks and it looks like a really cool tool.

Simone: The Swift part of Hound uses Fifth Lane. You get the same information you get locally there on Swift Lane and it integrates on GitHub. It’s super easy to set up, you just have to create an account on Hound and link your project on GitHub and that’s basically all. Actually, Hound commends your code directly on GitHub and is kind of fun to use.

Another tool which is similar is Code Cub, it’s just like Hound. I prefer Hound for personal reasons because it supports Disk Cleaner but also Code Cub does the same thing and it’s based on Tailor which is a rival of Swift Link.

Charles: Tailor, Swift Link, I get it.

Simone: Yeah, totally. I guess it’s still not over with the Tailor frameworks. Every two months, we have a new Tailor team in Swift.

Charles: Very cool.

Simone: I was talking about SonarQube. SonarQube doesn’t support Swift out of the box. It actually builds up on other tools like Lizard, Slather, Swift Link, and integrated [00:33:14] for Swift actually needs a plugin which is an open source plugin which can retrieve all the information from different sources and build your value into the tool.

Charles: I want to hear about French Kit, tell us about the conference.

Simone: French Kit is a conference here in Paris, France September 23 and 34. We have ten speakers from around the world, we have Boris Bügling, Jesse Squire, Marin from Alcatraz. We have a full day of conference on Friday and afternoon on Saturday with activities for the community like classrooms which is like a Genius bar for developers which we all [00:34:11] about an average or about accessibilities or how to make for instance a Swift web server.

Swift is the first iOS [00:34:25] conferencing in Paris which is kind of unbelievable for a big city like ours, but still. I’m working on that, September, I’m really excited to be doing that.

Tickets are still available on our website which is frenchkit.fr. It’s one of the cheapest conferences here. I shouldn’t say that. We actually have a really low price point at this day.

Charles: Alright. Well, it sounds like we’re slowing down so let’s go ahead and hit some picks. Jaim, do you have some picks for us?

Jaim: Sure, I’ve got one pick. Last week, I picked Curl Builder, some API tool. I attended a meet-up talk about API stuff where [John Chiang 00:35:14] who is the CTO of Runscope who has been doing API development and testing and that sort of thing for a long time, he went through his list of API tools for people that are working with APIs and trying to make sure they’re working like they want to. That includes us as iOS developers even though we’re on the client’s side. Just to verify that things are working correctly.

He gave a great list I’m going to post to Slide Deck with a lot of tools. We’ve got 70 tools for our listeners today. Lots of good stuff.

Charles: Layne, what are your picks?

Layne: Quick side note Jaim, the Curl Builder has changed my life so far, so thank you.

Jaim: Just wait, next level coming down the road.

Layne: Okay.

My pick is another book, mainly my picks have been books because I’ve been completely wrapped in them. All my free time has been going to them. Anyways, it’s called the Hero of Ages, it’s the last book of the Mistborn Series by Brandon Sanderson. I’ve basically been reading for two hours a day which is a whole bunch for me. Good book.

Charles: I’m going to real quick or maybe not so quick, I have been quick picking this on the other shows but last week I went to Wood Badge which is adult leader training for boy scouts. It’s a week long, and yes you wind up camping while you do it. I’ve heard of places where they do it in places where they have cabins but that wasn’t where I was.

I talk about it and the more I talk about it to people the more they’re going, “That sounds like one of those expensive executive retreats. And then I tell them that the attendee cost is like $150 and their jaw drops because it’s just so awesome. It was a pretty incredible experience and I feel like I came away from it both a better business person, a better leader, not just a scout leader but in other ways as well. I just feel like I’ve got such a better handle on things.

They talk some about scouts but it’s mostly about leadership and team building and things like that. I don’t know if I can really do it justice without somebody having already gone. But anyway, it was absolutely amazing and I loved it. I’m going to pick that, it was held up at the Tifie Boy Scout Camp which is at the Mountain Dell Boy Scout Ranch. It’s above Mt. Pleasant, Utah. It’s kind of halfway up the mountain and so you’re up on this bench and you just have this beautiful view over the valley and things like that. It was a great place to have it.

My other pick is going to be Boy Scouts of America just because I think it’s a terrific organization that does great things for young men and young women if they want to get involved in the venturing program. If you’re involved in scouts or you want to be involved in scouts, then go do it. It’s all volunteer basis, you’ll just volunteer, you have to do a little bit of training and then you can be a leader and then go to Wood Badge. That’s my pick.

Simone, what are your picks?

Simone: My pick is Post-Sole which is a framework which is made by old colleagues of mine. It’s Swift framework which provides access to [00:38:25] providers like iCloud. The interesting of that is you actually don’t need to fetch or mail blazing made core provided by Apple, you can do it with a different method. It’s kind of cool because it has a nice Swift API and it supports connecting to your mailbox, your iMap and also sending [00:38:54]. Also supports searching which is great, you can search with different filters on your mailbox and you don’t have to give at all, this is no credentials. It stays in your app once you’ve integrated it.

Charles: Alright, cool. If people want to follow up with what you’re doing or check anything out on Twitter or things like that, what do they do?

Simone: People can follow me on Twitter on my account which is [00:39:25]. They can follow my company’s blog which is [blog.zibia.fr 00:39:36]. It’s in French, I’m sorry. But it has a kind of a good articles about development in general.

Of course, follow our French Kit Twitter account which is @FrenchKitConf. Also, be sure not to miss the updates from [00:39:58] who organizes the conference with me.

Charles: Alright, very cool. Thank you for coming and talking to us about this.

Simone: It’s been awesome.

Charles: We’ll go ahead and wrap up the show and we’ll catch you all next week.

 

x