Nowadays, we are trying to use common approaches and well-known patterns to create an application with minimum effort and maximum value. We have great libraries and powerful frameworks that do routine operations for us. All that we are using in order to focus only on business logic. However, this chasing quite often leads us to , especially when it comes to implementing a feature without any ready solution for it. spaghetti code In this article, I want to share with you one powerful tool that, in my experience, not all developers value. Most programming languages have this tool, and it is a very often used tool in many frameworks - annotations. Do you like spaghetti? Let's look into an example that I bumped into a couple of years ago. I needed to implement excel spreadsheet parsing to put the parsed data into the database and vice versa - I needed to collect some data from DB and create a spreadsheet. In order to implement it, I used a well-known java library - . API of the library allowed to work on a low level and create a sheet, row, cell and etc., manually, which is very flexible, but code becomes absolutely not readable and unsupportable when it is needed to generate different excel spreadsheets. Since, as it usually happens, I needed to implement the feature in a short period of time, the first version of the application was terrible. Apache POI The implementation consisted of a data class which was a representation of a row with all the fields that are needed to parse. And a parser where the excel fields were parsed cell by cell and were put to the newly created instance of the data class. Nevertheless, the program was working perfectly and did what it needed to do. Problems started when the time to add some modifications came; the code was not readable. Even I, who wrote the code, couldn't find the right place to put the new lines to implement the new feature that I needed. Annotations. The rescuers The solution that saved the application from this spaghetti code was annotations. To get rid of the unsupportable code, I needed to put the logic of defining what column should be parsed, what data type contains in the cell, etc., to another place. And of course, the best approach here was to put this responsibility into the entity itself. I have created an annotation where I could put the name of the column for each field of the class. In the annotation, I also added a variable by which I could choose the color and font of the cell. By that, the code in the parsing class was drastically reduced. It was only one handler that dynamically created a spreadsheet by parameters taken from the annotations. It was a victory. Then to add any modification to the application, I just needed to create a class with the annotations. The solution worked pretty much similar to Jackson library, which parses a JSON using annotations, and there is no need, I think, to tell how convenient Jackson or similar libraries are. ({ElementType.FIELD}) (RetentionPolicy.RUNTIME) ColumnExcel { ; ; ; ; ; } @Target @Retention public @interface String "" name () default int position () ExcelColumnDataFormat ExcelColumnDataFormat.NONE cellTypePattern () default IndexedColors IndexedColors.AUTOMATIC cellColor () default ExcelTotalFormula ExcelTotalFormula.NONE total () default ColumnExcel columnExcel = field.getAnnotation(ColumnExcel.class); With evolving, the application got a new annotation using which a cell with a function inside could be created in the spreadsheet. The different fields could be multiplicated, subtracted and any common excel functions could be used in the generated spreadsheet. Also, the summary row has been added to show the sum by a column. And all that was done only by slightly modifying the main parser and just adding annotations to the classes. ( name = , position = , total = ExcelTotalFormula.SUM) BigDecimal variableC; ( name = , position = , cellTypePattern = CellDataTypeFormatPattern.PERCENTAGE ) { CellAddress(rowNumber, ).formatAsString() + + CellAddress(rowNumber, ).formatAsString(); } (position = , cellTypePattern = CellDataTypeFormatPattern.RUR) { + CellAddress(firstRowNum, ).formatAsString() + + CellAddress(lastRowNum, ).formatAsString() + ; } @ColumnExcel "Views" 4 private @ColumnExcelFormula "Conversion" 5 String public variableD ( rowNumber) int return new 4 "*" new 2 @ColumnExcelTotalFormula 4 String public static getVariableCTotalFormula ( firstRowNum, lastRowNum) int int return "SUM( " new 4 ":" new 4 ")" Conclusion With metadata, the code became more readable and much easier to support. Of course, annotations are not the fastest solution in terms of execution time. It uses reflection to get parameters in runtime, which consumes more time than the straightforward implementation. But does the game worth it today when we have very powerful hardware? This question is for each of you to decide we would prefer a couple of seconds faster or readable and easy to support solution.
![A Beginner's Guide To Annotations and Annotation Processors [Explained]](https://hackernoon.imgix.net/drafts/9313k2b4y.png?auto=format&fit=max&w=3840)
