s92025592025 / cse403-wi19-flint Goto Github PK

Even if can read all the files, the CMD tool won't do anything

(1/1pt) I could find the instructions to build the project easily from the repository
-The instructions are easy to find, conveniently located in the “Quick Start” section.
(0.5/1pt) I could reproduce the build on a machine matching the prerequisites mentioned in the instructions.
-The zip file provided in the instructions worked well for installing the build locally. The Flint CLI worked without issues, and correctly detected issues in one of our Java files
I was unable to install the IntelliJ plugin using the instructions under “Installing Flint”->”IntelliJ IDEA Plugin” (see below)
(1/1pt) The instructions were clear and easy to use.
-Instructions were clear and easy to understand. They are short and to the point.
(1/1pt) The continuous integration setup makes sense to me, and I could find the build history.
-The CI setup makes sense and the build history is easily findable on the Flint Github page.
(1/1pt) The continuous integration history includes at least one failing test.
-There are a few failing builds in the history.
(1/1pt) The continuous integration history includes at least one passing test.
-There are passing builds in the history.

I couldn’t find any report submitted for this week in the Flint repo (I wasn’t sure if evaluating that was part of this week’s feedback). When trying to install Flint as an IntelliJ plugin, after locating the Preferences-Plugins tab in IntelliJ, I searched for “Flint-403” as instructed but nothing came up. I have the (latest) free version of IntelliJ, so it’s possible it may be due to some kind of version differences. You may want to look into this to see if your plugin should be listed there.

I also tried to install Flint through the Intellij install plugin from disk option. I selected the flint jar file to be installed as a plugin, it came up as “Plugin display name here” with a generic description. Flint was not in any of the main plugin information. Also, I couldn’t find any icon for Flint or any extra toolbar. It would be helpful to provide a picture of what the icon looks like and where it would be located at. It didn’t seem to be installed properly taking these steps.

Remember to check if the relative path entered in the command line works like normal command line

(0/1 pt) The report or the README contains instructions to reproduce the initial results.
Neither the latest version of the report or the README contain information about results or how to produce them
(0/3 pts) The initial results are reproducible.
There was no information provided on how to reproduce any results
(0/2 pts) The report has a discussion of the results.
The report does not appear to have been updated for a few weeks, and does not contain any discussion of results
(0/1 pt) The report expands on the methodology and is complete.
The report has not been updated for a few weeks, so there has been no additional information provided about methodology.
(0/1 pt) The schedule is updated and there is a reasonable discussion on why it changed.
Because the report has not been updated, the schedule has not been updated. There is no discussion about any changes made to the schedule in the latest report.
(0/2 pts) The user manual is updated.
The manual does not appear to have been updated from last week.

There’s not much to say here. There have been no updates to the project in 10 days. It looks like the project has been abandoned or moved.

If possible, generate them from inline comment in code.

Grading Rubric
• (1pt) I understand the problem this group is trying to solve.
o Yes, they propose a flexible style checker that runs within an IDE and is programmed only in Java.
• (1pt) I understand why current solutions are insufficient.
o Yes, the current solutions for Java style checkers are either inflexible or require the developer to code an xml file. They propose a more flexible style checker that will be coded only in Java.
• (0.5pt) I understand this group's proposed approach.
o Partially. We understand what the general proposed concept, but are unclear on some of the details. How exactly the main generic rule will work and how exactly one can extend this rule and customize their own rule
• (0.5pt) I understand how this team will evaluate their approach.
o Partially. They state that they will evaluate their plugin based on how useful a developer feels about it. This seems like a weak way to do an evaluation. Some measurable statistics would be more helpful.
• (1pt) This team included a schedule.
o Yes, they did
• (0pt) Every item on this team's schedule is measurable.
o Most of the goals are not specific or measurable. “Build”, “Prepare” and “Test” aren’t measurable. Is it fully built? Is it built with all working features? If you write a single test, does that count as a “Test” goal?
• (1pt) This team included appropriate citations to related work, including from the scientific literature.
o Yes, citations to related work are included.

General feedback:

Flint sounds like it could be a useful tool. It is easy to understand from your description what the problem is and why current solutions are inadequate (Checkstyle being infeasible for those who don’t know XML, and google-java-format being inflexible/non-customizable). It makes sense in that if a developer codes in Java, they would be able to code their own style rules in Java as well. The idea of allowing users to simply extend a general “Rule” class to implement their own custom rules is appealing, as it would minimize the amount of work needed to create a new rule. As a developer, both the quality of my code and the speed at which I can write it are important, and Flint sounds like it would increase the former while minimizing impacts to the latter.
That said, there are some confusing parts of this proposal. What do you mean by “if Flint were to read only one file at a time, a client would not be able to make a rule for something that would need to consider multiple files”? If Flint is checking code style rules, why would limiting the number of files checked at one time prevent me from implementing certain style checks? It is unclear if you meant “lines” instead of “files”. You state that the general Rule class will “examine each line of a given Java file”, does this mean that I am limited to rules that only span a single line? If I wanted to implement a rule to prevent excessive consecutive lines of inline “//” comments in favor of “/**/” block comments, could I do this? Having an example of what you mean by multi-file rules would be useful to help understand what you mean.
You mentioned that Flint will come with several “common and uncommon” rules built-in; what are these rules? It would be nice to know, to accurately judge how many custom rules we would need to implement ourselves. Going into more detail regarding what the generic rule class does and how it can be extended would be helpful to know. Also, there is no mention which specific IDE(s) this plugin applies to. As a customer, I would need to know this ahead of time to be able to judge whether it would be of any use to me or my organization. Another thing to watch out for is the possibility that the user has to wind up implementing almost an entire linter when specifying their formatting rules. How will you make sure that the user isn’t bogged down with having to hand-write everything?
Overall, the tool seems like it will be really useful, but I would love to see some concrete examples of some of the more novel features you want to implement.

(1/1pt) The document builds on the previous submission
It does, however it didn’t seem like there were many changes from the last version
(1/1pt) There is a user manual and I could find it easily on the repo
The user manual is easily visible on the repo’s main page
(1/1pt) The user manual is self contained and well documented
All information needed to install, configure, and run Flint is contained within the manual
(1/1pt) The user manual contains all instructions required to use the tool
The user manual is very thorough and easy to understand
(1/1pt) The report contains clear implementation details
All details of the implementation seem to be laid out in an easy to understand format. The architecture diagram and its supporting text in particular are very helpful
(0.5/1pt) The team's plans are clear and measurable
The plans are clear, but there wasn’t much detail in the measurability of goals

REPORT:

The reasoning behind Flint’s utility is sound. It is clear to see that being able to run conditional checks through a programming language like Java vs. XML provides something that Checkstyle does not, and the ease of flexibility of Flint is something that Google’s Java Style Formatter does not provide. Your architecture diagram and its supporting text are clear and easy to understand.

A few notes, however. There seems to be a bit of ambiguity between your report and your manual in terms of creating new rules. The report states that custom rules will extend an abstract rule class, but the manual seems to imply that custom rules are created as their own class (not one that extends an abstract rule class). I might be interpreting it wrong, but you may want to clarify this better between the two. Also, as far as measuring success goes, can you go into more specifics about your user surveys? I.e. is the survey data quantitative or qualitative? How will you translate the results of the surveys into concrete measurable data? Also, it would still be nice to see a list of a few examples of rules that will be built into your tool.

USER MANUAL:

The User Manual formatting is fantastic, it looks fantastic and is easy to read. Instructions for installing, configuring, and running Flint are clear and thorough. The table of contents is a great addition, as well as using the md formatting to increase readability. I also liked the Quick Start section near the top. As a customer I appreciate a quick simple download link to get your tool.

A couple concerns, however. There are no future plans mentioned for this project. Even if it was just mentioned that this project is a work in progress and you plan to fully implement the rest of it (unless it is fully implemented already, then maybe what you hope to do with this tool in the future. Or what demographic you hope would use this tool. Or how you are going to distribute / test this tool with developers. Something along those lines). Another concern is the lack of implementation details. The user manual is fantastic from a customer perspective, but from a developer who’d like to contribute to the project, it would be nice to understand more about the implementation. Maybe even linking to the project report document and referring potential contributors there for more information.

Also, I’m assuming under “Creating New Rules” where it says to create a new class “RuleClassName.java”, that “RuleClassName” should actually be the name of the specific rule you would like to implement, but it was a bit unclear. You might want to explicity state if “RuleClassName.java” should be the exact filename, or otherwise state something like “Where RuleClassName = the name of your rule”. As noted above, there seems to be a bit of confusion between this and the report also in terms of extending an abstract class vs. not. You also might want to define early on what the “configuration file” is. The term is used in the Quick Start section at the top, but I didn’t fully understand what that file was until reading later on in the document.

Try to use bullet point to list things you did/plan to do in the future, let help you and reader to track stuff. Also, try the markdown's - [ ] XXX feature. It is cool!

Ref: https://homes.cs.washington.edu/~mernst/advice/progress-report.html

And, is it in a testable state?

Meta-NOTE: it doens't have to be a minimum viable product to be compiled and tried. So just give a hint on how to run you code and what am I running :)

Rubric:

(1/1pt) The document builds on the original project proposal
-Yes, the original proposal was revised and expanded upon
(1/1pt) There is an architecture diagram
-Yes, the architecture diagram was simple to understand. The explanations of each module below it were helpful
(1/1pt) The architecture diagram is explained in English
-Yes, it was explained clearly in English
(0.5/1pt) The system's interface is documented. (For graphical interfaces, a UI mockup should be included. For command-line interfaces, the document should explain how a user interacts with it. For components of larger systems, the document should explain how the component interacts with the system around it.)
-There is an explanation of the command-line interface, but no mockup of how this might look as an IDE plugin
(1/1pt) The document contains discussion of tools and APIs that the team plans to use
-Yes (Java, Gradle, JUnit, JavaParser, IntelliJ API)

Discussion:

The implementation plan looks good. I like that Flint includes both CLI and IDE interfaces, so that users don’t have to download two different tools if they want to be able to run this analysis in either environment. Implementing the built-in rules through the same process that a user would build custom rules is a good idea, as it will allow you to refine the process of custom-creating a rule at the same time that you create the built-in rules.

Acknowledging the limitations of Flint up front is helpful as well. It shows the reader that you’ve thought of what Flint is able to do and isn’t able to do and made it clear what both of those are. This allows user to compare your tool with others and see what works for their situation.

It was a bit confusing when you mentioned “However, it should be noted that this issue alone is not overly deterring, as there are numerous 3rd-party client applications for Checkstyle that are offered as IDE extensions.” Does this mean there are already versions of what you are proposing? How does Flint improve on these (or are they not implemented for some IDEs)? Also, it might help to include a mockup of what an error message inside IntelliJ might look like (e.g. when Flint detects an error, underlines it in yellow, and the user hovers over it).

Another concern is how you plan on measuring your success. Having more clearly defined metrics that you can quantify would be helpful. You state that one of your main motivations is to increase developer’s productivity. If you could find a way to measure that productivity increase, it would help show the success of your product.

When ever we try to run CLI version on Windows CMD, it constantly can't recognize the jar file or can't read the class in the jar file.

D:\UWGDrive\UW GDrive\CSE 403 A\CSE403-Wi19-Flint\Flint\build\libs>java -jar flint-0.1.jar -config-jar "D:\UWGDrive\UW GDrive\CSE 403 A\CSE403-Wi19-Flint\Flint\build\classes\java\main\BigDemo.jar" -config-class flint.DemoConfig -file-path ..\..\src\main\java\flint\CLIAdapter.java
D:\UWGDrive\UW GDrive\CSE 403 A\CSE403-Wi19-Flint\Flint\build\classes\java\main\BigDemo.jar is not a valid flintConfiguration jar

D:\UWGDrive\UW GDrive\CSE 403 A\CSE403-Wi19-Flint\Flint\build\libs>java -jar flint-0.1.jar -config-jar ..\classes\java\main\BigDemo.jar -config-class flint.DemoConfig -file-path ..\..\src\main\java\flint\CLIAdapter.java
flint.DemoConfig is not found in ..\classes\java\main\BigDemo.jar