使用{}分割大块代码以提高代码可读性-良好实践？
使用{}分割大块代码以提高代码可读性-良好实践？
提问于 2010-10-25 17:28:19
我正在考虑使用匿名{ }代码块来从逻辑上区分同一方法调用中的“代码块”，这(理论上)应该提高代码的可读性。
我想知道以下哪两个代码段对您来说更好？
另外，这两个代码段是否编译为相同的字节码?换句话说，使用{ }是否会以任何方式损害代码的性能？
选项1:没有{}编码的代码块
public static String serviceMatch(HttpServletRequest servletRequest, RequestTypeEnum requestTypeEnum, ...censorsed..., RequestStatistics requestStatistics) {
Request request;
// We get the parser that fits the ...censorsed..., effectively transforming the HTTPReqeuest to application local "Request*" object
RequestParser parser = RequestParserFactory.getParser(...censorsed...);
// Populate basic parameters, the "heavy" data will be lazy loaded
request = parser.parse(servletRequest);
// Instead of polluting the parsers let's put it here... (unless we identify meaningful justifications for the other alternative of changing RequestParser.parse() interface.
request.requestType = requestTypeEnum;
// Store the request statistics object on the request, so that we have access to it from all over the code
request.requestStatistics = requestStatistics;
// Update timestamp when request was parsed
request.requestStatistics._1_end_parseRequest = System.currentTimeMillis();
/*
* ...censorsed...
*/
MatchResult matchResult = Matcher.findMatch(...censorsed...);
/*
* ...censorsed...
*/
String reply = ReplyFormatFactory.getFormatter(...censorsed...
// Update timestamp when reply finished construction
request.requestStatistics._6_end_formatReply = System.currentTimeMillis();
return reply;
}选项2:带有{}的代码块
public static String serviceMatch(HttpServletRequest servletRequest, RequestTypeEnum requestTypeEnum, ...censorsed..., RequestStatistics requestStatistics) {
Request request;
/*
* Request parsing block
*/
{
// We get the parser that fits the ...censorsed..., effectively transforming the HTTPReqeuest to application local "Request*" object
RequestParser parser = RequestParserFactory.getParser(...censorsed...);
// Populate basic parameters, the "heavy" data will be lazy loaded
request = parser.parse(servletRequest);
// Instead of polluting the parsers let's put it here... (unless we identify meaningful justifications for the other alternative of changing RequestParser.parse() interface.
request.requestType = requestTypeEnum;
// Store the request statistics object on the request, so that we have access to it from all over the code
request.requestStatistics = requestStatistics;
}
// Update timestamp when request was parsed
request.requestStatistics._1_end_parseRequest = System.currentTimeMillis();
/*
* ...censorsed...
*/
MatchResult matchResult = Matcher.findMatch(...censorsed...);
/*
* ...censorsed...
*/
String reply = ReplyFormatFactory.getFormatter(...censorsed...
// Update timestamp when reply finished construction
request.requestStatistics._6_end_formatReply = System.currentTimeMillis();
return reply;
}谢谢你的评论马克西姆。
回答 10
Stack Overflow用户
发布于 2010-10-25 17:31:58
如果您考虑在同一方法中添加额外的{ }，只是为了提高可读性，我的建议是考虑将您的方法重构为几个较小的方法。
这些较小的方法具有更容易自己理解和更可重用的优点(如果它们是“松散耦合的”)。见单一责任原则。
Stack Overflow用户
发布于 2010-10-25 17:32:49
如果您认为在代码的某些部分(如选项2)周围放置括号是很方便的，那么应该将其移动到它自己的方法中。这就是提高可读性的原因。
顺便说一句，我还认为您不需要对代码的每一行进行注释。例如，即使没有注释，时间戳更新也是不言自明的。
Stack Overflow用户
发布于 2010-10-25 18:17:19
我通常不会在没有语法原因的情况下添加以大括号分隔的块，但是如果一个变量只需要在一个有限的范围内，我宁愿创建一个嵌套作用域，也不愿在较大的变量中间定义该变量(因为在后一种情况下，没有明确指出变量何时超出了“有用”范围)。
至于将这样的代码块提取到另一种方法中，我认为如果结果方法(1)都有一批合理的参数，并且(2)可以给出描述其行为和实际代码的名称，这是一个好主意。如果使用该方法需要传递过多的参数，或者必须查看方法中的代码以了解其调用方在做什么，那么我认为最好使用匿名作用域块。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/4017212
复制相关文章
相似问题
腾讯云开发者
