未加星标

Debugability Considered Useful

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二03 | 时间 2019 | 作者 红领巾 ] 0人收藏点击收藏

Developers are lazy. There’s nothing new about that. We even pride ourselves on it. Sometimes being lazy is a good thing, but most of the time it’s not something we should brag too much about. Let’s have a look at a few examples of developer laziness in action.

public SomeViewModel Map(Something something) { return new SomeViewModel { Name = something.Name, ListA = something.itemsA.Select(itemA => MapItemA(itemA, additionalParameter1, additionalParameter2)).ToList(), ListB = something.itemsB.Select(MapItemB).ToList(), ListC = something.itemsC.Select(itemC => MapItemC(itemC, additionalParameter3)).ToList(), ListD = something.itemsD.Select(itemD => MapItemD(itemD, additionalParameter4)).ToList() }; }

This is an example of some code that we’ve all seen before. Heck, I encounter this on a regular basis. You know, inlining code as much as possible in order to avoid declaring variables. The developer in question probably had a hard time coming up with variable names. Completely understandable. Coming up with names that express intent is one of the most difficult things that we face when writing code. But this is also where laziness becomes quite hurtful. Let’s have a look at another example.

foo.SomeMethod(new Bar(parameter1, parameter2), items.Where(item => item.Property1 == someFilterValue).Select(item => new Buzz { PropertyX = item.Property2, PropertyY = x.Property3 }).ToList());

This is a nasty one, isn’t it? While the previous example is still somewhat nicely formatted, this one is pretty bad. I’ve seen method calls like this where I had to horizontally scroll several pages in order to get to the closing semicolon. I sometimes wonder whether this is still laziness or just mere hatred towards the next person reading this code. Every time I’m horizontally scrolling in my code editor, I wonder what I did wrong to deserve such apathy. These examples communicate sloppiness and a disregard when it comes to readable code. In such cases I argue to improve the debuggability of the code.

“How difficult is it going to be in order to debug this code?” That is the question that we should ask ourselves more often. How difficult is it going to be to debug the code snippets from these two examples? It can be done, for sure. But is it going to be easy? Or is it going to be a bit more difficult than we would like?

For the first example, suppose that we want to inspect the items of the ListC property of the returned view model object. Where should we add a breakpoint? For the second example, suppose that we would like to inspect the items passed as the second argument to SomeMethod. How would we do that without any additional effort like stepping into the method to inspect the parameter or evaluating the LINQ expression itself during a debug session?

I’m definitely not advocating that we should spend more time using the debugger. In fact, debugging code is wasteful and we should avoid it as much as possible. But I do advocate for the debugability of code.

“ Debugging is worthless, but debuggability is everything.

― Some smart person

What do I mean by that? Let’s have a look at the improved versions of the two code example shown earlier.

public SomeViewModel Map(Something something) { var listA = something.itemsA .Select(itemA => MapItemA(itemA, additionalParameter1, additionalParameter2)) .ToList(); var listB = something.itemsB .Select(MapItemB) .ToList(); var listC = something.itemsC .Select(itemC => MapItemC(itemC, additionalParameter3)) .ToList(); var listD = something.itemsD .Select(itemD => MapItemD(itemD, additionalParameter4)) .ToList(); var result = new SomeViewModel { Name = something.Name, ListA = listA, ListB = listB, ListC = listC, ListD = listD }; return result; } var bar = new Bar(parameter1, parameter2); var filteredItems = items .Where(item => item.Property1 == someFilterValue) .Select(item => new Buzz { PropertyX = item.Property2, PropertyY = item.Property3 }) .ToList() foo.SomeMethod(bar, filteredItems);

This sure looks like more code compared to the initial version. That might be true. But we also immensely improved the debugabbility of the code. For the first example, suppose that we would like to inspect the items of the ListC property of the returned view model. At this point we even have two options. We can set a breakpoint on the line where we return the result variable. But we can also set a breakpoint earlier on in order to inspect the listC variable. The same goes for the second example where we have better options to debug the code.

But most importantly, we also improved the readability of the code. We also no longer have to horizontally scroll in order to grasp what’s going on. These days, decent code editors like Rider display a vertical line at the 120 characters mark. Whenever crossing this line while typing, a mental alarm bell should start to go off and we should consider the readability of the code.

Code that is easy to debug, is also very readable and easy to reason about. Therefore I suggest we should consider this attribute of code quality more often.

Software Design Core Skills
Debugability Considered Useful
Jan Van Ryswyck

Thank you for visiting my blog. I’m a professional software developer since Y2K. Ablogger since Y2K+5. Curator of the Awesome Talks list. Past organizer of the European Virtual ALT.NET meetings . Thinking and learning about all kinds of technologies since forever.

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

分页:12
转载请注明
本文标题:Debugability Considered Useful
本站链接:https://www.codesec.net/view/628134.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(21)