https://www.yegor256.com/2016/10/23/award-2017.html # SimonKagstrom/kcov (C++) + Travis CI + Github issue tracking - pretty much all commits lead to issues in Github, linked to issues + Github release management - lots of releases, lots of tags + Changelog with Github issues that entered each release + > 1year project (since 2010) + > 10.000 LOC + Code coverage and coverage report (https://coveralls.io/github/SimonKagstrom/kcov) - Github release management, BUT, older releases have no linkage to issues - Not clear if release process is automated, seems manual, even with Github release management - Code indentation/format, way comments are presented, doesn't seem to be very uniform across project, but could be because there are big differences between in terms of date specific classes have been last edited - Recurrent build failures for OSX compilers (even though linux compilers pass) - Not clear if using "Elegant" OO approach. Files with implementation of more than 1 class, many lines of code per file. Code looks a bit procedural on some parts. - quite a few big "chained" if statements and switches Comments: .Feels strange that the test folder seems a bit... un-updated .Test folder needs cleanup, and found some test files that don't seem to be actually testing anything # JnRouvignac/AutoRefactor I failed to build the project (tried to build with oraclejdk7, oraclejdk8, openjdk8 on tag "1.1.0") Issue tracking: + GitHub issues + GitHub pull requests - not all commits are traceable to issues. - untracked issues (comment in travis states that jdk8 is commented out till the version 1.1, but 1.1 is released already and jdk8 is still commented out) Release management: + GitHub releases - very rare and occasional releases - cannot reprodice release build at tagged commit CI: + Travis - CI is failing on master Code coverage: + cobertura/coveralls (according travis config) - code coverage is not integrated to build pipeline - didn't manage to build the project, so coverage is not clear for me Static analysis: + checkstyle Tests: + JUnit unit testing - unit tests are failing build at tag 1.1 Antipatterns: - utility classes (org.autorefactor.util.Utils, org.autorefactor.cfg.ASTPrintHelper, quite many of them) - static methods (org.autorefactor.ui.AutoRefactorHandler, more) - -ERs (org.autorefactor.environment.JobManager, org.autorefactor.cfg.CFGBuilder, lots of them) - getters/DTO (org.autorefactor.environment.Environment) - Constants (org.autorefactor.preferences.PreferenceConstants) ? Implementation inheritance (lots of org.eclipse.jdt.core.dom.ASTVisitor children, lots of org.autorefactor.refactoring.rules.AbstractRefactoringRule children. Probably forced by a dependency.) - Lots of instanceof reasoning (search by "instanceof" in repository) Other remarks: - Supporting only outdated version of Java (according travis configuration) - lots of commented out code - tight coupling (example: org.autorefactor.cfg.CFGBasicBlock has package-scoped methods, used by several of the classes from the same package) - lots of large complex multi-responsible classes with many private methods. # javaslang/javaslang (vavr-io/vavr) It's former javaslang. See http://blog.vavr.io/javaslang-changes-name-to-vavr/. Blame Oracle for this confusion. Issue tracking: + GitHub issues + GitHub pull requests - strange way of tracking changes. Instead of mentioning issue number in commits, they mention the number of pull request. The latter in turn is not nesessarily linked with the issue. Release management: + GitHub releases + Maven Central CI: + Travis Code coverage: + Jacoco + Codecov Static analysis: + Sputnik Tests: + JUnit unit tests + Basic JMH benchmarks Antipatterns: - Fluent API just everywhere. - Lots of statics in interfaces - Lots of default implementations in interfaces - Implementation inheritance (io.vavr.collection.Traversable children) ? Annotations (@Unapply, @Patterns) - Instanceof reasoning (search by "instanceof" in repository) Other remarks: + excellent documentation - large LoC per module - there is not actually much of OOP there. # HDouss/jeometry Issue tracking: + GitHub issues + GitHub pull requests - issue tracking is almost missing (project of one developer?) - commits are spontaneous - pull requests are not used Release management: - project is not ever released CI: + Travis Code coverage: + Jacoco + Coveralls Static analysis: - none Tests: + JUnit unit tests - There are also some integration tests in jeometry-double, but they aren't integrated to build pipeline. Antipatterns: - Static methods (com.aljebra.matrix.Sum, com.aljebra.matrix.TransposeMatrix) - Implementation inheritance (com.jeometry.twod.point.XyPoint, com.aljebra.vector.FixedVector, quite enough of them in jeometry-api - mixin inheritance style) - Instanceof reasoning (search by "instanceof" in repository) - Couple of -ERs (com.aljebra.field.impl.doubles.DecimalRandomizer) ? Annotations (@DimensionsEqual) Other remarks: + good documentation - default methods in interfaces (com.aljebra.scalar.Scalar) # ntpsec/ntpsec + Project is > 1 year old (seems it's maintained since around 1997) + Project is > 10.000 LOC (49535 lines of C, 72297 LOC in total) ? Code itself is well documented for the most part, but it's not OOP ? There seem to be quite an ammount of unit tests, but no clear coverage indicators ? Project is both on Github and on Gitlab, Issue tracking only on Gitlab ? There are rules documented in terms of, Code style, Git commit messages format, Versioning, among other rules, but most are not automated. - There are releases on GitHub, but each release on Github has no description of what went to release. - No displayable signs of automated releases (event though there are scripts for it) - No displayable signs of any CI setup - No displayable signs static analysis - No displayable signs of automated Coverage reports - 0 Pull requests on Github - 0 Issues tracked on Github - A considerable part of commit history is unlinked from issues # php-ai/php-ml + The project is well documented. Each functionality have good examples. The coding style is Clean and Understandable. The project is versioned. Lots of helpful comments. Github issue tracking. Github release management. Deployment is automated for git and composer. The project has tests for each functionality. Null return is avoided. - The project uses Getter and Setters. The project uses "Traits" instead of Composition. Some classes use Static methods. In GIT history the messages do not describe what exactly was changed. Messages are not descriptive. Some classes like DecisionTree are too long and have lots of methods. These are the example classes where I mostly found these issues: -- KernelIPCA.php use of getters and setters use of Static methods -- All Exception classes use of Static methods -- DecisionStump.php use of traits use of setters -- ClassificationReport.php use of Static methods use of getters and setters -- DataTransformer.php use of static methods # LobbyOS/lobby + Github issue tracking. Github release management. but only 4 release. Good documentation and comments. Travic CI. - Lots of code in admin module is written in Procedural programming. Lots of Utility classes. Lots of Static methods. Git history messages are not descriptive. They are shallow. Core classes are big, more than +500 lines. Lots of Null checking and Null returning. These are the example Classes where I mostly found these issues: --DB.php This is Utility class. Lots of Static methods. Getters are used. --FS.php This is utility class. Lots of Static methods. --Modules.php Losts of Static methods. --Router.php Use of Static methods. --Response.php Use of Static methods. Use of Getters and Setters. --Request.php Utitlity class Use of Static methods. Use of Getters and Setters. --Hooks.php Utility class. Use of Static methods. Use of Getters and Setters. # onqtam/doctest (C++) + Travis CI + Clean documentation + Github release management, releases + git tags + Code coverage and coverage report + > 1year project - Squashing git history? https://github.com/onqtam/doctest/commit/b1e7e147a8a71d67e38dbcc20687399bd73e563a - Unclear Github issue tracking, no clear linkage between most commit messages and issues - Files with thousands of lines of code, though the some classes seem "Elegant" everything is thrown together into files - Not clear if release process is automated, seems manual - most PRs getting merged with CI failing - quite a few big "chained" if statements and switches - Where are the Unit Test files and where is Static analysis, how 99% coverage is a bit of a mystery for me ?! Comments: .Overall feels very strange in terms of maintainability, few big thousand lines files .The number of LOC itself seems strange, because most code is placed in C++ header files, with thousands of LOC, but when I run a counter, only 9122 LOC for C++ header files (less than 10.000) . Overall documentation is good, but the code doesn't seem elegant or maintainable # iboB/dynamix (C++) + Travis CI + Clean documentation, very organized, https://ibob.github.io/dynamix/ ? Poor Release management, 2 releases for 1.1.0 and 1.2.0, with change-log but there's no linkage to actual issues on Github or links between commits and issues ? Seems to have quantity in terms of unit tests, but no clear Code coverage and coverage reports. - "It lets the user compose and modify types at run time". - No Github issue tracking, no clear linkage between all commit messages and issues - Commit history seems lost -> readme says project has been around since 2013, but commit history starts on June 19 2016 with version 1.0.1 Comments: I'm not investing more time on this one, "compose and modify types at run time" lost it for me. # atk4/data + Github issue tracking. Github release management. 32 releases. Good documendation and Comments. Travic CI. Covered with Tests. Project consists of +10K lines of code, but half of them are tests. Pure core project consist of less than 10K lines of code. - Lots of null checks. Some classes have more than +800 lines of code, and class Model is like God object Some methods are also big, they need to be divided into smaller one. Use of Getters and Setters. Use of Traits in some classes. The messages in git history are also not descriptive. These are the example Classes where I mostly found these issues: --Field.php Class is quite long. +400 lines. The function normilize has +130 lines. Use of Getters and Setters. --Join.php Use of traits instead of Composition. Class is big, and have lots of methods. --Model.php Use of traits instead of Composition. This class has +1800 lines of code. It is God object. The functions save and set have more than +120 lines of code. --Persistence.php Use of traits instead of composition. Use of static methods. --Persistence_SQL.php The class is huge. +900 lines of code. # laravel/framework + Github issue tracking. The project has 285 releases. The project is versioned. The project has great documentation and code comments. Travic CI. Deployment is automated, for Git and Composer. Covered with tests. Clean Code. The project is huge. - The project uses traits in lots of classes. Lots of Null checking and Null returning. Anti-patterns like Singleton, ORM and God object is used. OOP and Functional programming concepts mixed. Reflection is used. Getters and Setter used in lots of classes. Lost of Static methods used. Lots of Utility Classes used. These are the example Classes where I mostly found these issues. There are more, but I list some of them: /Auth //Access --Illuminate\Auth\Access\Gate.php Use of traits instead of Composition. Use of Getters OOP and Functional programming concepts are mixed. //Console --Illuminate\Auth\Console\AuthMakeCommand.php Use of traits instead of Composition. //Event --Illuminate\Auth\Events\Authenticated.php Use of traits instead of Composition. --Illuminate\Auth\Events\Login.php Use of traits instead of Composition. --Illuminate\Auth\Events\Logout.php Use of traits instead of Composition. --Illuminate\Auth\Events\PasswordReset.php Use of traits instead of Composition. --Illuminate\Auth\Events\Registered.php Use of traits instead of Composition. //Password --Illuminate\Auth\Passwords\DatabaseTokenRepository.php Use of Getters. Static methods used. // --Illuminate\Auth\Passwords\AuthManager.php Use of Getters. OOP and Functional programming concepts mixed. --Illuminate\Auth\EloquentUserProvider Null returning. Reflection is used in createModel method. Use of Getters and Setters. --Illuminate\Auth\SessionGuard.php Use of traits instead of composition. Some methods return null. Lots of null checking. Use of Getters and Setters. Class is quite long, it has +700 lines of code. //Broadcasting //Broadcasters --Illuminate\Broadcasting\Broadcasters\Broadcaster.php Use of reflection. Use of Static methods inside methods. -Illuminate\Broadcasting\Broadcasters\PusherBroadcaster.php Use of Static functions. Use of Getters. //Cache --Illuminate\Cache\Repository.php Use of traits instead of composition. Lost of Null checking and Null returning. Use of Getters and Setters. Use of Static methods. Use of Reflection. //Container --Illuminate\Container\BoundMethod.php Use of static methods. Use of Reflection. --Illuminate\Container\Container.php OOP and Functional programming concepts mixed. Null checking and Null returning. Use of Static methods. Use of Getters and Setters. Class is long, It has +1200 lines of code. //Databse --Illuminate\Database\Capsule\Manager.php Use of traits. Use of static methods. Use of Getters and Setters. --Illuminate\Database\Eloquent\Model.php Use of traits. Use of static methods. Lots of Null checking and Null returning. Use of Getters and Setters. Class is big. It has +1400 lines of code. It is like God object. --Illuminate\Database\Eloquent\Builder.php Same comments like in Model.php. --Illuminate\Database\Connection.php Same comments like in Classes. //File System -- Illuminate\Filesystem\Filesystem.php Use of traits. Use of Static methods. //HTTP --Illuminate\Http\Request.php Use of traits. Use of Static methods. Use of Getters and Setters. Bull checking and Null returning. //Routing --Illuminate\Routing\Route.php Use of traits. Use of Reflection. Null return and Null checking. Use of Getters and Setters. Class is big, It has more than 800 lines of code. --Illuminate\Routing\Router.php Same comments like in Route.php class # zetaops/ulakbus (Python) About 25K lines of python code: + Github issues + Really extensive contribution guide (https://www.ulakbus.org/wiki/wiki.html) + Code extensively documented, in Turkish though + Short release cycle + Both low-level and high-level tests (with selenium) + Usually files aren't too long (about 300 on average), only 13 files are more than 500 loc, and only 2 have more than 1K loc (1057 and 1283) + Haven't found really huge methods, longest methods are about 30 loc - Changelog is outdated - Code style is stated in docs (PEP8), but it's not enforced and I've found violations - Test coverage is unknown - No CI (there's only .sh script which runs tests (but it's non-blocking to failing tests, e.g. there is no `set -e` in it) - About 90 None usages, mostly due to framework interface (seems that they've written this framework themselves), but some of them really unnecessary - Couple of silent error passing (except: pass is a nasty Python antipattern) - There are really big models (ulakbus/models/ogrenci.py) - 74 static methods, I've found the only one which is used as a secondary constructor. - About 370 getters (methods starts with get_, not counting Python built-ins) and 92 setters (mostly ORM methods). Some of those getters don't even return anything, so I suppose they're storing some global or class variables which are being accessed outside then. (BankaBorcGetir.get_data for example) - Implementation inheritance everywhere - Whole utility module called "lib" As a summary, it's an MVC app without easily distinguishable purpose unless you look up the docs or dig into the code (but due to really good dev-docs you can start to contribute very fast). It is written quite good for such kind of app (no GOD classes, no huge methods), but it's heavily influenced by its non-OOP framework and ORM. # mgramin/sql-boot (more details here: https://gist.github.com/amihaiemil/239169ef959fc064307e06aef6d30fd4) The code base is too small! (less than 3000 LoC) Quick overview (+/- mean ups and downs) (+) Ticketing + ticket referencing (+) milestone set on each ticket (+) Code coverage calculated and decent (> 70 %) (+) Knowledge of the used framework; doesn't confuse it with JavaEE (+) Every class has an interface (+) No getters/setters POJOs (+) Class naming (+) Quick user guide and live demo options. Also, a lot of badges dislaying various states. (-) project has less than 10k LOC (-) no PRs, writing on master (-) There are 3 releases so far, but no automation for them/ (-) Even though there is a Maven profile for qulice, it is not run during CI builds (-) Packaging of the classes. (-) No technical documentation and no proper javadocs 1) Traceable changes/Github tickets: There are tickets in the github repo, most of them opened by the owner for tracking purposes. However, there are no Pull Requests, the author simply commits on master and adds the commit message fixes #123 -- this references the issue and closes it automatically, it's a Github feature. 2) Release process: The project has 3 releases (1 after 94 commits, 1 after 76 commits and 1 after 34 commits) -- they seem regular, but I didnt notice any automatisation of the process. It seems that he simply uses the Github release button. 3) Static analysis: The project has a Maven profile for qulice (see here), but I do not see it being used neither in .travis.yml, nor in appveyor.yml 4) Test coverage: The project calculates its code coverage using Jacoco maven plugin and sends the report to Coveralls, via the coveralls Maven plugin. The coverage is only calculated in one of the CIs (which makes sense), in Travis. Also, there is a coverage badge on the main README.md file 5) Non Stop development: The project seems to be well structured, all the tickets have the milestone set. Also, there are 3 releases so far, seemed to be done at a more or less equal amount of commits. Also, the tickets are referenced in the commit messages. 6) Patterns used: Framework: The main framework is Spring Boot, which is basically an alternative to JavaEE. To this regard, the author understands what Spring Boot is and uses it right, since the app is properly packaged with Maven Assembly Plugin, and run with Docker. There is a Dockerfile to run the application. This is very good, since I wouldn't have been surprised to see a Spring webapp ran on a JavaEE platform like Glassfish. Code: As far as I can tell, every class implements an interface, which is very good. I've also noticed Fake implementations for the respective interfaces. There are no POJO classes either, didn't notice getters and setters. However, there are a few JsonProperty annotations, in order for Jackson (JSON library) to be able to parse the objects into JSON. Lombok is used for overriding toString. Naming of the classes is also ok -- just a few Controller classes, which are used by Spring to expose the REST api. What I don't like, however, is the package structuring: each interfaces seems to have its package and then a child impl package, which holds the implementation. This seems too granular, and it's a sign to me that the developer wanted to just clearly structure the classes, without thinking of access modifiers and how these classes will access each other's methods, for instance. E.g.: Interface FileSystem is in package: com.github.mgramin.sqlboot.tools.files.file_system, while its implementations are in package com.github.mgramin.sqlboot.tools.files.file_system.impl -- this is mostly the pattern for all the interfaces. 7) Documentation: The project has a short, but fair documentation for the users, on the README.md (including options to try the project directly on Heroku). It also has a demo db and you can use Docker to spin up a demo. However, I didn't find any technical documentation and the javadocs of the classes are rather poorn (some of them are even empty, only the @author tag is present). For me, as a developer, it would be very hard to start working on this, I have no clue of the overall architecture, how all those classes work together for instance. The only thing I understood was the entry point, which are those controller classes and Application class. For instance, I have no idea what is it with the folder config -- it only contains a tree of subfolders and some README.md files pointing to Wikipedia technical articles about topics such as Stored Procedures. I would love to see an archirecture.md file, containing a quick overview of the codebase, maintypes, terminology etc. # goreleaser/goreleaser +Github issue tracking. +The project has 168 releases. +The project is versioned. +The project has great documentation and code comments. +Travic CI. -It seems that project is File Oriented rather than Object Oriented. -Lots of Structs(Classes) are in the same file. -Functions are created out of the Classes which makes then Global. -Null checking -Coding style is like in Procedural Porgramming. -Some varaibles are created out of the methods or Objects. -Project is less than 10K lines. -gooleaser\checksum\checksum.go These methods(functions) (SHA256, calculate, doCalculate) are used like in procedural programming. They need to be converted or wrapped into Struct(Classes). Null checking is used. -gooleaser\config\config.go Lots of Structs(Classes) are inside one file. Move them into seperate. Some methods(functions) need to be converted into struct(Class) beacuse they are used like in procedural programming. Null checking is used. -gooleaser\internal\context.go Varables are declared outof function and objects. Lots of Null checking. --All other files are almost same problems as above. # kogoia/MRTD.NET +Coding style is Clean. +Dependency injection is avoided. +Classes and Methods are small, and Named Correctly. +Among C# projects it has cleanest code followed by OOP concept. -309 commits but do not have any releases. -No github Issue tracking. -Static Class and Static methods are used. -I found one Null checking. -OOP and Functional Programming concepts mixed. These are the example Classes where I mostly found these issues: -SmartCardApi.Infrastructure.LinqExtensions.cs Class and Method are Static. -SmartCardApi.Infrastructure.Cache.cs Null checking is used. -SmartCardApi.MRZ.CheckedDigit.cs Functional programming concept is used. (a, b) => new Product(a, b) -SmartCardApi.Infrastructure.Sum.cs Functional programming concept is used. (prev, next) => plus(prev, next.Value()) -SmartCardApi.SecureMessaging.Pipe.SecureMessagingPipe.cs Functional programming concept is used. (prev, next) => { Console.WriteLine("{0} - {1}", next.StartIndex.Value(), next.Count.Value()); return prev.Concat( _securedReader.Transmit(new ReadBinaryCommandApdu(next.StartIndex, next.Count)) .Bytes() ).ToArray(); }); Lambda expression is used. # mafagafogigante/dungeon Quick overview (+/- mean ups and downs) (+) over 10k LOC (+) Development via issues and PRs. (+) No monster classes -- The only bigger classes I noticed where the entry points (classes Game and GameWindow). The rest seem to be < 150 loc. (+) Javadocs are present on most classes. (+) Regular releases (+) Automation of some release tasks. (+) Static analysis check with Checkstyle (+) Fine overall documentation of the versioning, build and contributing schemes (+) Milestones attached to issues (-) Very low test coverage (25%) (-) No interfaces. There are almost no interfaces in the codebase. 1) Traceable changes/Github tickets: Changes seem to be implemented in an organized way, via open issues and PRs (240 closed issues, 50 open issues and 112 closed PRs) -- it is the best project I've reviewd, from this point of view. 2) Release process: The project has many releases and they seem to be done on a regular basis. There also seems to be an automation involved in the process, which adds a new tag in the repository, updates the pom.xml version and some information in the wiki: https://github.com/mafagafogigante/dungeon/blob/master/release.sh 3) Static analysis: The project uses Checkstyle for static analysis check. 4) Test coverage: Test coverage is calculated and displayed via https://codecov.io. However, it is very low (25%) 5) Non Stop development: Development iterations seem well documented via milestones set on issues. Also, versioning of the releases is well documented here: https://github.com/mafagafogigante/dungeon#versioning-scheme. 6) Patterns used: This is a desktop application. It is, in fact, a game. Framework: Desktop application, UI written with Java Swing. 7) Documentation: This project is really well documented -- it has both README.md and a wiki. The versioning and build schemes are explained well, and the project ran smoothly on my machine from the first trial. Even the final jar ran fine and the game started. There is also a detailed CONTRIBUTING.md # javascript-obfuscator/javascript-obfuscator Nobody volunteered to review it. So, I will review it myself. Yegor. - commits are not linked to issues/PRs in most cases + Travis CI + code coverage 98% + issues and PRs - releases seem to be done manually + tslint for static analysis of TypeScript The project seems to be interesting. # klapuch/Remembrall + Github issue tracking. The coding is clean and understandable. "This is cleanest OOP code that I ever seen in PHP". No Traits, Null return is used. Classes are small and have a few methods. Not any God objects. Deployent is automated for Docker. Covered with tests. Travis CI. Static Methods are avoided. ORM is avoided. - In some classes the OOP and the functional programming consepts are mixed. But still code is clean. I found getters in two classes. In some classes, functions are called using call_user_func_array, which is like Reflection. Not enough Documentation and Comments. Project has 904 commits on github, but does not have any release or version. These are the example Classes where I mostly found these issues: --ParticipatedUsers x Use of functional programming with OOP. --ApiErrorCallback calling function via call_user_func_array. It is also like Reflection. --EmailSubscription.php Use of functional programming. --CollectiveParts.php Use of functional programming. --FakePage.php Use of Getters. --FakePart.php Use of Getters. # zahasoft/repository +The project has comments. +Covered with tests -Project is young and to small, first commit was made Jun 18, 2017. -The Project Has 31 commits but does not have any realises. -No issue tracking. -No documentation. -The project has less than 2K lines of code. -Naming of Classes are not properly managed. Some classes consist of 4 nouns which makes difficult to read. These are the example Classes where I mostly found these issues: --Zahasoft.Repository.SelectManyModel.cs The method SelectManyModel takes 5 params put them into one object. Null return is used. --Zahasoft.Repository.EntityFramework.DependencyExtensions.cs The class and all methods inside of it are static. In the methods called AddRepository it is used lots of checks for typeof. --Zahasoft.Repository.EntityFrameworkCommandRepository.cs Null checking is used. The method GetDateTimeNow is static. --Zahasoft.Repository.EntityFrameworkQueryRepository.cs Class has long name. I found lots of static methods, null checking and null returning. --Zahasoft.Repository.EntityFrameworkUnitOfWork.cs Class name consists of 5 words, make it shorter. OOP and functional programming concepts are mixed. Checking for typeof, which is bad. Null checking. Use of static method. -- Other classes are too small to say something. # DrBookings/drbookings: (more details here: https://gist.github.com/amihaiemil/29b5ccd6902e243cce29ee0dec2c857d) Quick overview (+/- mean ups and downs): (+) over 10k LOC (+) ticketing (started later in the project's life) (+) code coverage calculated and displayed in a badge. (+) multiple releases containing latest fixes (+) code seems to be well organized (+) class naming (-) no PRs, writing on master (-) really low code coverate, according to the badge (< 10%) (-) no automation of the release process (-) poor release descriptions and no milestones on open tickets (-) no static analysis check (-) "Test" classes in the codebase (-) No interfaces (-) No javadocs (-) No technical documentation 1) Traceable changes/Github tickets: There are about a dozen tickets, in total, in the repo, meaning the owner started ticketing rather late in the project's development. There are no Pull Requests, the author simply commits on master and adds the commit message fixes #123 -- this references the issue and closes it automatically, it's a Github feature. 2) Release process: The project has 21 releases so far, but it doesnt seem to be an automatic process. All of them are done by the developer, with titles such as "Awesome", "Good", "Try it out". 3) Static analysis: I didn't find any static analysis checker. There is one single pom.xml, under the folder simple. The codebase seems to be under that folder, while all the others all build/configuration/plugin folders? The build script from .travis.yml is mvn clean package -Dheadless 4) Test coverage: Code coverage is calculated and displayed with a badge on the README.md page. However, it is really low. 5) Non Stop development: While there are a lot of releases, I see no (or poor) release notes and no milestones set on the open issues 6) Patterns used: The application is developed with JavaFX and comes as a desktop application (.jar file to run). It doesn't seem to work with a database, but rather with XML files on disk. JAXB and its annotations are used to serialize/deserialize objects. The codebase well organized, but I noticed all sorts of *Test classes, which I don't think should be there. Most classes do not implement interfaces, and of those which do, most of them are javafx. specific interfaces, the classes implementing them probably do so for convension or because it is required by the framework. There are absolutely no javadocs. However, the class names seem to be OK. 7) Documentation: The project has a User Wiki here, but absolutely no technical documentation. Besides that, the repository is very polluted with IDE/workspace specific files, which should have been gitignored (e.g. Eclipse's .project and .classpath files). I would have no clue where to start if I were to contribute on this project. I don't understand why the repository can't have a simple maven project in it, instead of having all sorts of folders and plugins etc. In this particular project, with such an old framework as JavaFX, I would clearly expect some strong technical overview/documentation + javadocs on every class. # flyimg/flyimg + The project is well documented and covered with tests. The coding is clean and understandable. The project is versioned. Lots of comments are used. Github issue tracking. Github release management. Deployment is automated, for Docker, Git and Composer. - Project Depends on Silex and Symfony components. So, If we do not count Silex and Symfony Components, the project itself is about 2K lines of code. The project uses lots of Getters and Setters. Some functions return Null instead of Throwing Exception Some Classes instantiated from Depricated Classes of Silex and Symfony. Reflection is used. In git history the commit messages do not describe what actually was changed. The messages are shallow. The Project uses God objects of Silex and Symfony that have classes more that 500 lines of code. These are the example Classes where I mostly found these issues: --ControllerResolver Chenking for (instance of) Class extendes Depricated Class Silex\ControllerResolver, which also uses depricated function like doGetArguments(); --InputImage use of Getters and Setters Null or Empty string return --OutputImage use of Getters and Setters Null or Empty string return --CorController PHP file content is created using ob_start and ob_end_clean; "ob_start(); include(ROOT_DIR.'/src/Core/Views/'.$templateName.'.php'); $body = ob_get_contents(); ob_end_clean()"; use of Getters and Setters --ImageMetaInfo Use of Getter and Setter; --OptionsBag use of Getters and Setters --ImageHandler Null return use of Getters and Setters --ImageProcessor use of Getters and Setters Null return and Null checking use of Reflection # miso-belica/sumy Project is too small (cloc says it has only 4K lines of all files in total) # simplcommerce/SimplCommerce +Github issue tracking. +Github release management. but only 3 release. +Covered with tests. +Deployment automated for Docker. +Travis -Naming of Classes, Properties and Methods not properly done. They are confusing. -Anti patterns like Repository, Dependency injection and ORM are used. -Some methods are too long. -OOP and Functional Programming concepts mixed. -Lambda expressions are used. -Null checking. -Lots of Annotaions are used. These are the example Classes where I mostly found these issues: --SimplCommerce.Module.ActivityLog.Controllers. MostViewedEntityController.cs Dependency Injection is Used. Annotaions are used. Lambda expression is used. --SimplCommerce.Module.ActivityLog.Data.ActivityRepository.cs Lambda expression is used. --SimplCommerce.Module.Catalog.Components.CategoryBreadcrumbViewComponent.cs Class name is too long. Lambda expression is used. Dependency Injection is Used. --SimplCommerce.Module.Catalog.Components.CategoryMenuViewComponent.cs Dependency Injection is Used. Lamda expression is used. --SimplCommerce.Module.Catalog.Components.CategoryWidgetViewComponent.cs Samething like in above classes. --SimplCommerce.Module.Catalog.Controllers.BrandApiController.cs Dependency injection is used. Null checking is used. Anotations are used. Lamda expression is used. --SimplCommerce.Module.Catalog.Controllers.BrandController.cs Lambda expression is used. Some methods are too long. -SimplCommerce.Module.Catalog.Controllers.CategoryApiController.cs Anotations are used. Dependency injection is used. Null checking is used. Lambda expression is used. -SimplCommerce.Module.Catalog.Controllers.CategoryController.cs Samething like in class CategoryApiController.cs --The same for all controllers in SimplCommerce.Module.Catalog. -SimplCommerce.Module.Contacts.Controllers.ContactApiController.cs Lots of Annotaions. Lots of Null checking. # dkhmelenko/Varis-Android Android client for travis CI. Overview: I can`t find out any reason for this application to get quality award. This code has been written in fully procedural way. A bunch of utility classes. I can`t find out at least one immutable class. Some Cons: - Test names does not explain what we expect to test. As example testParseXmlDateTime. - Mocking in tests. - Project structure does not divided to infrastructure entities (for android sdk) and core or business entities. - I can`t find out some core domains! - Package Common\constants will be a rubbish dump in the future. But now it contains not bounded to each other constants. - Bunch of utility classes. - Function arguments must be final. One pro: + I can find out one OOP thing. This is `log` package. But there are mutable objects without any hierarchy. Also i can`t find out any interfaces. Ci & automation: Project use travis-CI. Project maintain code coverage. But code coverage is 17%. Project does not maintains static code analysis. Also: Project has releases, I can't find out changelog Commits are small. I can't find out how to build the project into readme file. Rating: 2\10 # pmed/v8pp (C++) + Travis CI - < 10.000 LOC (Sum is 5392) - singletons, statics, getter - Purpose is to "bind from C++ code such items as variables, functions, constants with a function set(name, item)" - Coverage ? Static analysis Comments: I'm not investing more time on this one, it's clearly not "Elegant" OOP # ribtoks/xpiks (C++) + Clear milestones + Clear issue organization, bug tracking, and labelling + Github release management - lots of releases, lots of tags, properly linked to issues + Travis CI + Organized suite of tests + > 1year project (since 2010) + > 10.000 LOC ? Unclear Github issue tracking - Some commits have no reference to issues, but almost all issues link to commits. ? Code coverage? Static analysis? ? Written Coding guidelines, but doesn't seem to be automated - Getters, setters. - Classes with lots of different methods that do different things This seems to be by far the most maintainable and well organized. I think maybe it needs more automation, but it's, of all projects, the one I could simply grab and start contributing. Read my Overall conclusions at the beginning. "My money" would be on ribtoks/xpiks (C++) or SimonKagstrom/kcov (C++) in that order. Had, overall, more "intangible" quality than the others. Overall I'm also left with the feeling "are there any more other projects to review"? If I had to pick one it would be ribtoks/xpiks. As for the other projects, they're good efforts on different fronts but not "winner material" for the contest. # octaviospain/Musicott Audioplayer and playlist manager. Overview: Project has a domain core. Core contains obvious abstractions: Player, Playlist, MusicLibrary and etc. It seems like true oop but it is not true. Objects are not immutable living organisms in this world. Objects are puppets with getters and setters in this world. Let's look at some details: Codestyle `If` expression must be with {} It is not defined what code style is used. True OOP Project has a domain core: Player, playlist and etc. Domain core contains classes instead of interfaces Too many responsibility for each of them. Objects are simply data containers. They uses for transferring data between runners and tasks. Objects are not immutable. Too many getters and setters. Not null safety. Classes must be final\abstract. I can`t find out static methods. Too few tests. Domain classes has a few documentation. Also: It has release history, changelog and a few issues. Commits are not small. CI & automation: It uses travis CI. Project maintains code coverage. But it only 28% It uses sonarcloud.io for static analysis. Rating: 3\10 + 0,5 for AC\DC in readme. # ev3dev-lang-java/ev3dev-lang-java This project designed to build Software for Robots with EV3Dev hardware. Overview: Most classes is interlayer for reading data and writing commands to the bus. This classes looks like true OOP classes. They make some abstraction (may be good abstraction for users) for interaction with command bus. But this classes do not encapsulate some state. They do not have some behavior. They encapsulate only knowledge how to properly send command to the bus. They are utility classes, nothing more unfortunately. Let's look at some details: Tests: There are some mocks in tests. Tests names does not transparent. Too few tests. Tests contains word `name` two times. Example: testEV3DevPlatformOnBrickPi3Test(). Ideally, `test` must be omitted at all. Some tests do nothing. Test code coverage not defined. Style: Code formatting is not perfect. It is not defined what code style is used. True OOP: Project has a domain core. Domain core contains classes instead of interfaces Domain core classes are utility classes. There are too many getters and setters in the project Too many magic numbers. it's terrible. Example: public SensorMode getGyroMode() { return getMode(2); } Classes must be final or abstract Sysfs is a static. Other classes uses Sysfs silently. This class must be decidedly injected to other classes. Most classes implements some interface. Also i find out some interface segregation. Also: I like readme in this project. It contains examples, quick introduction how to create first Project and deploy it. And even some videos! It has release history, issues. It contains Release notes. Awesome! Commits are small, but is not self described. Do not defined rules for static code analysis. CI & automation: Project use travis-CI. Ci only build project and run tests. No test coverage, no code static analysis. It contains several gradle files. Good idea! Rating: 4\10