-3

I'm working on a project with 3 other backend developers and 3 front end devs. Also playing the role of architect for 3 other projects. One issue I see is that most developers are not formatting code, not paying heed to the results of static code analysis (part of issue is time, part managers who are more interested in getting it to work right away).

Another issue is that some are using Ecdlipse, a few STS, and a few Intelli g.

How do you enforce code formatting, coding standards? I know we can apply them in the pipeline, but 2 projects don't have a pipeline. I know that is not a good practice. But I cant change that.

Are there ways to enforce formatting before commit or git push (all projects use git as repo).

Or better yet during maven or gradle build? Most use maven, few are using gradle. All projects are in Java. Mostly spring, some other frameworks.

At the very minimum would like a commandline tool that does the same thing as what eclipse and intelli j do with the Formatting (shortcut : Ctrl-shift-F) command.

tgkprog
  • 595
  • 6
  • 18
  • 1
    Does this answer your question? [Workflow for git / code formatting / commit hooks etc](https://softwareengineering.stackexchange.com/questions/357822/workflow-for-git-code-formatting-commit-hooks-etc) – gnat Aug 18 '21 at 06:49
  • No, that was a 2017 question, was hoping something new by now. My managers want some basic style also. SO I need to do it. The devs also agree to it. Basic minimum agreement is there. Not about spaces vs tabs, but a space between terms, operators, things *most* devs them selves agree too once they see their own old code and see the other way ... – tgkprog Aug 18 '21 at 11:07
  • Seems to be me if eclipse has formatting, is open source, then no reason for it not to be available from commandline, just some blessed developer who knows the eclipse code base has to make it accessble from commandline – tgkprog Aug 18 '21 at 12:39

2 Answers2

3

Allow me to share a personal experience about enforcing rules around styles and formats.

Not long ago, I had to compare and merge a forked code (2 lanes) with more than 1 year of changes in each lane. Lanes were being developed by two different teams, from different companies. Two teams that never minded coordinating with each other.

I estimated the task in one month and a half (full time), several meetings with both teams and migrating both lanes to a single repository (one team was working with Subversion, the other with Gitlab). In consequence, the release of the version had to be delayed by two months (at least). To make it even more fun, I had to do the job so that both teams could keep working on their respective lanes.

The customer was so pissed at this, that it couldn't but bought my suggestion about establishing corporative code styles, formats and tools. Because these things could help to reduce the complexity of the task and avoid similar scenarios in the future.

Formatting the code removed more than half of the changes. Took me 1 month (full time) and 2 meetings (8h) with both teams. Despite these things, there were so many differences that I had to do it manually with Meld and Eclipse.

Contrary to what Ewan's answer suggest, enforcing styles and formats (among other things) is convenient. It's something to consider before writing any line of code and everybody must agree, no matter personal preferences or likes. The context matters, the project's need for code management dictates whether we must enforce these practices or not. If you are accountable, yours is the choice and the responsibility so the team have to accept it.

Developers on their own, can not impose personal preferences over the needs of the project for code management. The project's dictates, the accountable decide, the responsible ensures and everybody executes. As professionals we are, we have to be capable of adapting ourselves to the circumstances.

Ok, how to do it?

The simpler way is from the package manager. Gradle, Maven, Ivy, etc. This way the style and format policies are managed alongside the source code they serve. Additionally, make it executable in different contexts (CI pipelines)

Is there a way to do basic formatting from the command line

Yes. Maven and Gradle plugins usually wrap libraries that do the job. You could simply download the lib and use it as an external tool. However, you will find the integration with the package manager to be more convenient and simpler to use.

You could also make a shell script to execute the plugin. Not sure about Gradle or Ivy, but Maven allows specific goals executions. For example:

#formatter-maven-plugin
$ mvn formatter:format
Laiv
  • 14,283
  • 1
  • 31
  • 69
  • thanks. in my case its not just my voice. i over look such things or at most ask them to format once in a way so at least see spaces before and after terms, operators etc like `a = b;` vs `a=b;` the devs see the need too. Is there a way to do basic formatting from command line ? thanks – tgkprog Aug 18 '21 at 11:11
  • The simpler and convenient way is to enforce either Maven or Gradle and choose a plugin. Or choose one plugin supported by both tools. I say convenient because whatever has to be executed by CLI can be omitted. The package manager is hardly omited. – Laiv Aug 18 '21 at 11:23
  • 1
    It might [interest](https://code.revelc.net/formatter-maven-plugin/dependency-info.html). The plugin is compatible with both Maven and Gradle but uses Eclipse styles and code formats. – Laiv Aug 18 '21 at 11:36
1

Formatting the code with a tool will eventually boild down just to redo the indentation, it would be a small but widespread change not worth the pain. Apart from the fact that often it does not work very well, It will be a lot more difficult to use the history because last change of a lot of code will be flattened to the same commit, especially painful when you have questions like what changed first? Is this a change made for a reason or just to align it to this other change?.

Standards are something the group should agree upon. If the group cannot find an agreement the team leader or the project manager should be involved. But is it worth it? Probably it is better to discuss more serious points like alarms from the code inspection tools on circular dependencies.

The fact that different developers work better with different IDEs shouldn't have any impact on the standard, it is true that changing many small settings like tab length might be boring, but different IDEs can produce the same code if you really want.

FluidCode
  • 709
  • 3
  • 10
  • yep, super would be to put these hints in .settings file in the repo and IDEs pick them up from there, and devs can edit again if they really want to/ need to. We need a new standard! – tgkprog Aug 18 '21 at 17:10