Because nobody wants to review a PR where half the diff is just import reshuffling.

Have you ever proudly submitted a pull request, only for your reviewer to come back with: “Why did all the imports change?” You didn’t touch them. Or did you? Your IDE did. Silently. Ruthlessly. Without asking.

Fear not — In this blog post, I will show you how to configure IntelliJ IDEA and Eclipse so that your imports always follow a clean, consistent, agreed-upon layout across the whole team. One setup, no more import wars. 🕊️

*You can thank me with a coffee here if this helped you saved time for you and your team ! * 😄

📐 The Target Import Layout

This is the structure we all agree on. Tattoo it on your brain:

// ✅ Block 1 — JDK standard libraries
import java.sql.Timestamp;
import java.util.List;
import java.util.Map;

// ✅ Block 2 — Third-party libraries (org.*)
import org.apache.commons.lang3.StringUtils;
import org.apache.commons.lang3.math.NumberUtils;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.springframework.util.CollectionUtils;

// ✅ Block 3 — Internal / company packages (com.*)
import com.archyoshi.db.read.CommonOperations;
import com.archyoshi.db.read.FlatJsonBlob;
import com.archyoshi.db.write.GenericWriteOperation;

// ✅ Block 4 — Static imports (always last)
import static org.assertj.core.api.Assertions.assertThat;
import static org.mockito.ArgumentMatchers.anyString;
import static org.mockito.Mockito.doCallRealMethod;

🧠 IntelliJ IDEA Setup

Step 1 — Open Import Layout Settings

Go to: Settings (Ctrl + Alt + S / Cmd + ,) → Editor → Code Style → Java → Imports tab

Step 2 — Configure the Import Layout

Scroll down to the Import Layout section and set it up in this exact order. Use the + button to add entries and the blank line button to add separators:

Step 3 — Recommended Supporting Settings

Still in the Imports tab, make sure these are configured:

• Class count to use import with ‘*’: Set to a high number like 999 to disable wildcard imports.
• Names count to use static import with ‘*’: Set to 999 as well.
• Uncheck “Layout static imports separately” — we handle static placement ourselves via the layout above.

Step 4 — Apply & Run

Hit OK, then run Optimize Imports (Ctrl + Alt + O / Cmd + Option + O) on any file to see the magic. ✨

🌑 Eclipse Setup

Eclipse doesn’t have a native drag-and-drop import layout UI like IntelliJ, but it can be done cleanly via its Code Formatter and Organize Imports settings.

Step 1 — Open Import Order Settings

Go to: Window → Preferences → Java → Code Style → Organize Imports

Step 2 — Configure the Import Order

You will see an Import Order list. Clear the existing entries and recreate them in this order using the New button:

ℹ️ Eclipse automatically adds a blank line between each top-level group — no manual separator needed.

Step 3 — Disable Wildcard Imports

On the same screen, set:

• Number of imports needed for .*: 99
• Number of static imports needed for .*: 99

Step 4 — Apply & Run

Hit Apply and Close, then trigger Organize Imports (Ctrl + Shift + O) on any file to validate.

🤝 Sharing the Config With the Team

Rather than having every developer set this up manually (and inevitably someone getting it wrong), both IDEs support config export:

• IntelliJ: File → Manage IDE Settings → Export Settings → select Code Style schemes → share the .zip.
• Eclipse: File → Export → General → Preferences → select Java Code Style → share the .epf.

Import the file on your end, done. No excuses. 🎯

Don’t hesitate to comment with another subject you would like to see me post about !

If after reading this guide your imports are still scrambled — that’s on you (or your teammates). At least, I tried. 😄

La seconde édition de l’après-midi du DDD ou #AMDDD s’est déroulée le 20 juin 2019 dans les locaux de Microsfost à Issy-Les-Moulineaux. L’événement a été organisé par 42Skillz avec, comme animateurs, Bruno Boucard et Thomas Pierrain, à leurs côté plusieurs invités, je cite : Xavier DETANT, Chloé GRANDIN, Radwane HASSEN, Audrey NEVEU, Pablo PERNOT et Alexandre VICTOOR.

J’ai assisté a cet évènement très enrichissant, et je vais partager avec vous l’expérience que j’ai eu lors de cet event.

La présentation était très originale, car au lieu d’être un enchaînement de talks et de sessions de coding, c’était sous forme d’une pièce de théâtre. Chaque scène a mis en lumière un aspect de la vie quotidienne de développeurs d’une société fictive nommée TicketOffice.

Voici quelques problématiques mises en lumière par cette belle pièce de théâtre :

• Le turn-over des employés les plus expérimentés sur une appli fais conduit fatalement a un échec si le code ne respecte pas les bonnes pratiques qui lui permettent d’être relus / compris et maintenu par d’autres développeurs.
• Quand la communication entre l’équipe de dev et leur client n’est pas assez poussée, les dév parfois se retrouvent à redévelopper des briques de code qui ne sont pas dans leurs cercle de responsabilité. Parfois même, ils se peut qu’ils codent des éléments qui ont toute une équipe dans la société dédiée mais qu’ils n’ont en tout simplement pas connaissance.
• Quand les discussions avec le métiers ne sont pas assez clarifiées et précisées on peut se retrouver avec des éléments (comme des règles métiers) très ambigüe ou parfois contradictoire.
• Quand on dépend d’autres équipes, et que notre base de code n’est pas assez “protégée”, on peut être victime de nos dépendances, il faut donc s’outiller correctement pour s’en prémunir.

Quelques idées qui pour apporter des solutions à ces problématiques :

• Quand on est face à un sujet de grande importance et qu’on souhaite réellement tout faire pour que ça marche, il faut également s’en donner les moyens, par exemple en s’assurant que les gens qui connaissent la base de code partage assez de connaissances avec ceux les nouveaux et qu’ils les fassent monté en compétence avec un accompagnement pour qu’ils deviennent fiable et capable de de contribuer efficacement au projet.
• Un des bons moyens d’être sur la même longueur d’onde que celle du client est de faire un atelier (ou plusieurs) atelier d’Event Storming en utilisant un maximum de moyens visuels afin d’illustrer correctement les idées et de les faire aboutir à un même concept clair pour tout le monde.
• La pratique du Domain Driven Design devient alors un bon moyen pour que le code représente un maximum le métier, donc s’accorder sur les termes métier employer pour désigner les mêmes éléments et d’une importance cruciale.
• Si on remarque que notre application est souvent hors service, et que la raison provient souvent de nos dépendances, il faut chercher différent moyens de s’en prémunir, il y a par exemple l’utilisation de l’Architecture Hexagonale d’un côté, mais encore une autre manière d’y remédier est le Anti Corruption Layer

Je vous laisse donc redécouvrir cette belle après midi en vidéo ici:

meanwhile you can check the About Me page :)