使用{}来分割大块代码以提高代码可读性 - 良好实践?

Max*_*ler 15 java performance coding-style code-readability

我正在考虑使用匿名{}代码块在逻辑上区分同一方法调用中的"代码块" 的选项,这(理论上)应该提高代码的可读性.

我想知道以下哪两个代码段对你的眼睛更好?

另外,2个代码段是否编译为相同的字节码?换句话说,可以使用{}以任何方式伤害代码的性能吗?

选项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;
 }
Run Code Online (Sandbox Code Playgroud)

选项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;
 }
Run Code Online (Sandbox Code Playgroud)

感谢您的评论,Maxim.

Don*_*nut 55

如果你想{ }在同一个方法中添加额外的东西只是为了便于阅读,我的建议是考虑将你的方法重构为几个较小的方法.
这些较小的方法具有易于自身理解并且更可重复使用(如果它们"松散耦合")的优点.参见单一责任原则.

  • @Maxim Veksler:听起来像是对我过早优化. (18认同)
  • @Maxim Veksler:虽然我不知道你申请的细节,但我认为你在这一点上错了.引用Effective Java,_Strive编写好的程序而不是快速的程序.一个编写良好,松散耦合和可读的程序将使您在分析和识别这些问题时更容易纠正性能问题.此外,您可能_think_正在帮助提高性能的事情可能不会,甚至可能阻止您稍后改善某些领域的表现. (3认同)
  • 我最近发现了这本书:重构:通过Martin Fowler改进现有代码的设计.我希望它早一点.这是一本必读的书.编译器能够通过不将代码分解为方法(例如,及时补充 - http://en.wikipedia.org/wiki/Java_performance)来进行更好的优化.你需要在重构之前和之后进行分析,然后你现在获得了你失去的东西. (3认同)
  • 如果你为新的小方法使用好名字,你也可以"评论" (2认同)
  • @Maxim:你实际上*测试过这段代码的性能,发现有一个大方法比调用几个小方法要快吗?如果您没有对此进行测试并使用真实世界的结果做出决策,那么您只是在猜测. (2认同)

Kar*_*nek 13

如果你来到状态,将括号括在代码的某些部分(如选项2)中会很方便,你应该将它移动到它自己的方法.这就是提高可读性的原因.

顺便说一句,我也认为你并不需要评论代码的每一行.例如,即使没有评论,时间戳更新也是不言自明的.

  • +1用于推荐每行的评论. (7认同)