Uploaded image for project: 'Yetus'
  1. Yetus
  2. YETUS-488

Checkstyle reports new error if the file still longer than expected

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Resolved
    • Minor
    • Resolution: Fixed
    • 0.4.0
    • 0.5.0
    • Precommit
    • None

    Description

      Given a java source file which is originally longer than the checkstyle defined value then we get the following warning every time the length changes and we run the checkstyle plugin:

      ./beeline/src/java/org/apache/hive/beeline/BeeLine.java:1: warning: File length is 2,373 lines (max allowed is 2,000).
      

      The problem is, that the checkstyle output is changed:

      From
      ./beeline/src/java/org/apache/hive/beeline/BeeLine.java:1: warning: File length is 2,373 lines (max allowed is 2,000).
      
      To
      ./beeline/src/java/org/apache/hive/beeline/BeeLine.java:1: warning: File length is 2,365 lines (max allowed is 2,000).
      

      Since the checkstyle_calcdiffs does not find the new line in the original output, it marks it as a new error, and gives -1 to the result of the checkstyle plugin.

      This is true for every error message where there is a number in the text. Not exhaustive examples are below:

      • Line length
      • Row length
      • Function length
      • Number of attributes
      • Indentation

      I think we should be reluctant to give -1 without a reason so it would be good to remove these errors.

      I have yet to find the ideal solution for the issue:

      • An easy patch could be to remove the numbers from files before the diff (note: it does not effect the final diff-checkstyle-<MODULE>.txt output messages). This would mean that the warning will give -1 only the first time when the error text is occurred, and will not give -1 if the numbers are changed, like
        • File become shorter, but still longer than expected
        • File become even longer
        • Indentation changed but still problematic
      • A more sophisticated patch could do this only for specific errors, or even check the value and give error when the line length grow.

      To be honest, I think the second solution would complicate the code too much, and make it dependent on the specific checkstyle messages, so I do not like it.

      I am even hesitant about the first one, because the change I introducing with it might have unwanted consequences.

      Do anyone has better ideas? I would be happy to implement them, if someone points me to the right direction

      Thanks,
      Peter

      Attachments

        1. branch-checkstyle-hadoop-tools.txt
          33 kB
          Allen Wittenauer
        2. diff-checkstyle-hadoop-tools.txt
          0.1 kB
          Allen Wittenauer
        3. patch-checkstyle-hadoop-tools.txt
          28 kB
          Allen Wittenauer
        4. YETUS-488.00.patch
          1 kB
          Peter Vary
        5. YETUS-488.01.patch
          3 kB
          Peter Vary
        6. YETUS-488.02.patch
          3 kB
          Peter Vary

        Activity

          People

            pvary Peter Vary
            pvary Peter Vary
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: