Traveller, Adventurer, Geek, Passionate about Algorithm, founder of webtutsplus.com, Entrepreneur, and explorer, connect me https://twitter.com/Nilmadhabmondal
Thanks, though I asked for your thoughts on it, not someone else's musing on the topic.
To address those points on that external site:
"It's another dependency" - yes, it is, yes, I have to modify the IDE too. But does it follow that I shouldn't deploy into Kubernetes because I have to install kubectl?
"Enourmous coupling, use interfaces instead" - this is more about where Lombok is used, and is a choice of how the workman uses the tool. I wouldn't use a sledgehammer to replace a window in my house.
"Removal of getters and setters hides code" - sure it does. But that doesn't mask anything, and by extension of the "hiding code is bad" argument, surely, no-one should use Spring either!
"Builder hides problems that would be a compile failure" - see javax validation. Your problems just went away.
"Lombok doesn't work with Spring variable injection" - cool, I've never seen a valid use case of having getters/setters in Spring config classes, why would anyone want equals() and hashCode()? Surely the answer is simply "don't use the tool where it's of no benefit!"
So, I ask again, what problems have you (or others) seen with Lombok in big projects?
Please note, I have no vested interest in, or affiliation with, Lombok.
Traveller, Adventurer, Geek, Passionate about Algorithm, founder of webtutsplus.com, Entrepreneur, and explorer, connect me https://twitter.com/Nilmadhabmondal
I guess that is nothing wrong using Lombok in general or for that matter usage issues with any project size. I think it requires some degree of coding style and coding disciplines. We all know each developer have their own style of coding, understanding and implementation strategies. And this is what could create problems in a multi teams involved in coding excercise in a project where the lead will have to constantly monitor use and abuse of Lombok and the time spent to explain and educate. Lombok powers you to encapsulate lot of boiler code as a trade off to making code look concise. But the devil lies in the details. And architect and leads doesn’t want to spend unnecessary time to control Lombok style coding in their project design only to later increase code maintenance expenses.
I think Lombok probably thrives in a full stack style project where an individual is responsible from top to bottom and Lombok can help faster delivery with less coding. But the code management expense could increase if the project is handed to another developer or team where they will have to learn the nitty gritty of shorthand decisions that were made.
Also, the style lombok generates codes away from using real member variable names could create problems during debugging and placing of breakpoints in generated code(?) or watching a variable value change in object construction and building by using Lombok annotations.
Thanks, but I am a Software Architect & Lead - I spend no time maintaining code style across my team, whatsoever, regardless of the frameworks in use. We have automated tooling for that. We have a group chat/discussion about style issues, a consensus is reached, and we put that into the code lint monitoring.
Code style, is not, in my opinion, a reason to use (or not) any framework.
I have never seen Lombok "generate codes away from using real member variable names" - do you have any examples? The IDE plugins exist to mitigate the debugging problem that you're describing, and if you have problems with object state during constructors, your constructors sound like they're overly complex.
I'm genuinely interested to see if someone has actually encountered a problem using Lombok, that wasn't as a result of using the wrong tool (or at the wrong time).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We actively use Lombok, across ~50 projects that are all in Production environments.
I'm curious, what problems have you seen with it on "big projects" ?
levelup.gitconnected.com/be-carefu...
Thanks, though I asked for your thoughts on it, not someone else's musing on the topic.
To address those points on that external site:
So, I ask again, what problems have you (or others) seen with Lombok in big projects?
Please note, I have no vested interest in, or affiliation with, Lombok.
To answer your question, no personally I have never faced the issue. My team leads are against it, so we didn't implement it with lombok.
And that's a perfectly valid approach - I have worked with Leads & Architects that didn't like things like Lombok.
I guess that is nothing wrong using Lombok in general or for that matter usage issues with any project size. I think it requires some degree of coding style and coding disciplines. We all know each developer have their own style of coding, understanding and implementation strategies. And this is what could create problems in a multi teams involved in coding excercise in a project where the lead will have to constantly monitor use and abuse of Lombok and the time spent to explain and educate. Lombok powers you to encapsulate lot of boiler code as a trade off to making code look concise. But the devil lies in the details. And architect and leads doesn’t want to spend unnecessary time to control Lombok style coding in their project design only to later increase code maintenance expenses.
I think Lombok probably thrives in a full stack style project where an individual is responsible from top to bottom and Lombok can help faster delivery with less coding. But the code management expense could increase if the project is handed to another developer or team where they will have to learn the nitty gritty of shorthand decisions that were made.
Also, the style lombok generates codes away from using real member variable names could create problems during debugging and placing of breakpoints in generated code(?) or watching a variable value change in object construction and building by using Lombok annotations.
Thanks, but I am a Software Architect & Lead - I spend no time maintaining code style across my team, whatsoever, regardless of the frameworks in use. We have automated tooling for that. We have a group chat/discussion about style issues, a consensus is reached, and we put that into the code lint monitoring.
Code style, is not, in my opinion, a reason to use (or not) any framework.
I have never seen Lombok "generate codes away from using real member variable names" - do you have any examples? The IDE plugins exist to mitigate the debugging problem that you're describing, and if you have problems with object state during constructors, your constructors sound like they're overly complex.
I'm genuinely interested to see if someone has actually encountered a problem using Lombok, that wasn't as a result of using the wrong tool (or at the wrong time).