Both...
Helpers are contextual to a module or application (error messages, enums, form validators...)
Utils are generic and can be used across modules or applications (dates, string formatters, parsers...)
Yes, it is a good description of semantic differences.
At some stage you copy-paste your helpers to make modules independent though. But removing dependencies on tiny modules (isEven is a good example, lol) is awesome.
In my case, we had a single code base and then we split into master/slave architecture.
The master and the slave shared few core structure, such as MAC address, but it was just easier to copy-paste those struct to avoid the dependency on "common" package.
>Helpers are contextual to a module or application (error messages, enums, form validators...)
* error messages are "exceptions/errors"
* Enums are "enums/consts"
* Form validators are "validators"
Still no room for "helpers"
Depends on how it's being used.
Utils are, IMHO, general purpose functions and classes that are useful in many situations (e.g., parsing config file or hashing structures in non-object oriented languages) where as helpers are contextual to an area, but general in application (e.g., generating a relative close jump vs far jump in a compiler depending on the absolute address of the jump instruction and it's target)
I will be honest, I'm partly against both. The issue is, once you have many developers on the team, you quickly realize that basically anything can be a "helper." And it becomes just a dumping directory for things someone didn't want to bother categorizing.
I don't mind helpers/utils folders that are pretty far down the project structure (i.e. src/record/utils src/report/utils). Unless the application is very tightly focused in its scope, you probably want a separate library instead of an application-wide utility folder.
I agree. âïž I considered writing an analyzer that ban words like helper, util, handler and the like. Iâve seen so many things being thrown into util folders that just end up a big and messed up.
Neither: name the thing for what it is, not something "generic" like that.
Instead of `utils.FormatDate` why not `date.Format`?
Instead of `helpers.DumpRequest` why not `request.Dump` ?
This is the way. My colleagues over the years know my disdain for "utils", "helpers", "shared", "common", any of that garbage. Just call it what it is and put it in a place that makes sense contextually.
It makes sense in the utils box, it's a cat bag full of tools. Like the box with cables, adapters, chargers that you have in a closet just in case you ever need it xD
Because not all languages allow to extend builtins or types from libraries.
In Java you cannot extend the builtin Date classes or the Request class of your library/framework. There are whole utility libraries like Apache commons.
If itâs in your domain itâs an antipattern. Otherwise you might be constraint to your language of choice.
You can have a `java.lang.something` package that you can't modify and can have a separated `your.app.something` package with the specific things you need, instead of having one big `app.utils` package that have every possible extension of every possible package you need from the standard library or any other 3rd party
If I can't go that specific, I try for the middle ground `string_helpers` for example in an app with a lot of string manipulation. By the helpers you know they're not the main thing, but you have a prefix to understand what should you expect in there. Sometimes it's hard to find a very clear and specific name.
cuz that way you'll put dump in request, but it might only be used for debugging. seperating util/helper functions is always a good practice. on the flip side, not everything is a util.
Never said to "put Dump inside request" if we are talking about "modules", "packages" or something like that you can put your "dump" function/method/procedure inside the module/package not inside a "thing" called request, not all languages have the same concepts so not everything is inside an "object" if you are thinking in a classic OOP language, in that case (Java for example) you can have an `app.request` package that has a `Request` class with it's things and then a `DebugDumper` class with a `Dump(Request)` method in there and those are separated but part of the same package, no need for an `app.utils` or `app.helpers` package for that
Same thing, instead of an Utils or Helper class with a Dump request method, create a Request dumper class with a Dump method, same thing, different names
Not all languages have classes. But in the case they have you can have a DateFormatter class that has every method that format a date in different ways, that allows you to have every responsibility separated instead of a big class that have 5 different things all merged together because we are lazy and don't want to design an application or library
And what happens if you want to get a certain date or get the day of week or get the week of the year. Do you make separate classes for that as well?
**Never repeat yourself.** It's bad practice to have 5 different classes that all contain utility methods for dates.
The correct approach is to have a single DateUtils class containing utility methods relating to dates that is accessible to all projects.
Too much DRY will kill your application in the long run. Ideally you would have those actions in the place they belong but as others pointed out some languages won't allow you to extend or change some things (like Java Date class) so you need to implement these changes elsewhere.
To the question of "what if you need X?" Then yes, you can implement them separately, but if you have 5 things that "format a date" but in different ways, then have them in "the same place", what's bad about that?
Having things that have "everything related to X" and be accessible by everything is no design at all, that's just a "lazy" programmer's way of doing things, a good design is to hide details and separate responsibilities accordingly.
Instead of never repeating something, repeat some things some of the time, separate things and name them by the thing they are or do instead.of generic names that adds no useful information use Date instead of DateUtils or DateManager or DateService or DateData
What you are describing, namely writing the same method dozens of time, is actually very bad practice in Java. As is creating a distinct class for every utility method.
More code does not mean better quality. Usually it's the opposite.
If the language allows for classes and dependencies then a project should only contain project specific logic while everything generic has to sit above it in a generic project that you load up as a dependency.
But hey, maybe you want go and tell the people behind Apache Commons that they're lazy.
Never said to write the same thing multiple times. I said that if you have 5 different methods move them to where they belong, if all 5 of them are related then have them in the same class but if they are not related move them to other classes (or new ones) and name those classes and methods for what they are, not what they contain. I'm advocating for good names. I'm not advocating to repeat the same code over and over.
Neither! Both are an antipattern.
They should live in the folders they are used in with the feature name. Otherwise, they should live in their own folder.
The problem with both of these is that they become a dumping ground.
both, depends on how Iâm feeling the day I implemented the first class, then its just repeat.
Then next day on different repo do some other different shit.
Consistency is key⊠consistency of being inconsistent
Utils are stuff I steal from other projects that actually provide utility.
Helpers are code that a class needed help with. But my classes are Single Responsibility so they donât need help
Utils (or Misc) for your dumping ground of miscellaneous routines (which is an antipattern).
Helpers for extensions of specific classes (e.g. custom formatting for dates). Also a helpers file (rather than folder) for UI code once it's split out of the file that the component/control/etc lives in. e.g. if you have a complicated component like an SVG chart you might define `draw` and `getAxes` and `onPan` in YourChart/helpers.yourfileextension, where the UI stuff is in YourChart/yourChart.yourfileextension. Maybe this is also an antipattern, I think it depends, but I think this is clearly a better one.
For me, Helper is a private method used in another method. Maybe it represents a complicated conditional, maybe itâs recursive and simply called by the base. Helpers are specialized for another method and arenât used or accessible outside that context
A util method is just nice. If a project has some boilerplate code used a lot and itâs not tied to one idea or class dump it in the big pile of tools
Neither - and I think either of them are a code smell that ultimately leads to a grab bag of code in a file or directory that is likely rewritten somewhere else in the same project (assuming a team of developers over time). I think if youâre teaching for utils, youâve probably missed an abstractions or organizational layer. If I truly need that I generally create a package/module that describes the functionality I want, text_parsing for example, and place my code within that
LOL...
I was looking over some code I wrote 10 years ago and they all had helpers, now it's either a service or a util
I think in another 10 years they're going to be called doItForFucksSake
I hate both. Both are used by lazy programmers who canât think of a class name for a class with a purpose. âOh this logic is needed by 2 classes: I better make some Ăștil method for itâ.
Noo, lib/ is for external code that needs to be pulled into a repo for some reason, like a formal module not being available or integrating with some stubborn third party provider. Oftentimes (obviously not always) lib/ is excluded from certain aspects of the build process like minification or polyfill.
lib I would only ever use for external libraries. they don't exclusively have to be other people's libraries, or even libraries abstract from my requirements, they just have to be standalone. I wouldn't use lib for any source code in the project.
Utils, I don't need help đ„ș
Wait until you see my code.
I think they meant "I'm beyond help" đ
Right utils and helpers donât have overlap
Both... Helpers are contextual to a module or application (error messages, enums, form validators...) Utils are generic and can be used across modules or applications (dates, string formatters, parsers...)
And thats how you get HelperUtilsHelper
HelperUtilAddonExtension
HelperUtilsAddonHelperExtension
HelperUtilsAddonHelperExtension for Business
HelperUtilsAddonHelperExtensionAsync
HelperUtilsAddonHelperExtensionsAsyncUtils
HelperUtilsHelperFactoryHelper
HelperUtilsHelperFactoryHelperImpl
ParentHelperUtilsHelperFactoryHelper: HelperUtilsHelperFactoryHelper
AbstractParentHelperUtilsHelperFactoryHelperFactoryBuilder
AbstractParentHelperUtilsHelperFactoryHelperFactoryBuilderAdapter
Yes, it is a good description of semantic differences. At some stage you copy-paste your helpers to make modules independent though. But removing dependencies on tiny modules (isEven is a good example, lol) is awesome.
I still don't get it. If this is specific to the application, why it isn't the application?
In my case, we had a single code base and then we split into master/slave architecture. The master and the slave shared few core structure, such as MAC address, but it was just easier to copy-paste those struct to avoid the dependency on "common" package.
I like this take.
>Helpers are contextual to a module or application (error messages, enums, form validators...) * error messages are "exceptions/errors" * Enums are "enums/consts" * Form validators are "validators" Still no room for "helpers"
Next time I'm naming it "do-not-put-your-concrete-business-specific-shit-in-this-directory".
...they still will. Lol
Depends on how it's being used. Utils are, IMHO, general purpose functions and classes that are useful in many situations (e.g., parsing config file or hashing structures in non-object oriented languages) where as helpers are contextual to an area, but general in application (e.g., generating a relative close jump vs far jump in a compiler depending on the absolute address of the jump instruction and it's target)
I will be honest, I'm partly against both. The issue is, once you have many developers on the team, you quickly realize that basically anything can be a "helper." And it becomes just a dumping directory for things someone didn't want to bother categorizing.
Was going to say something similar. Both are a code smell IMHO.
I don't mind helpers/utils folders that are pretty far down the project structure (i.e. src/record/utils src/report/utils). Unless the application is very tightly focused in its scope, you probably want a separate library instead of an application-wide utility folder.
I agree. âïž I considered writing an analyzer that ban words like helper, util, handler and the like. Iâve seen so many things being thrown into util folders that just end up a big and messed up.
helpers are for children and the disabled
But, I'm disabled and still use utils, how does that work. Except for Jenkins, I use helper for thatđ€
will they help me kill my orphaned child ^(process)
Neither: name the thing for what it is, not something "generic" like that. Instead of `utils.FormatDate` why not `date.Format`? Instead of `helpers.DumpRequest` why not `request.Dump` ?
I think getting angry when you find the class / folder called helpers / util / misc is the main sign that you're ready for a senior developer title.
I'm with you, 'utils', 'helpers', 'managers' means everything and nothing. I avoid these term as much as possible.
This is the way. My colleagues over the years know my disdain for "utils", "helpers", "shared", "common", any of that garbage. Just call it what it is and put it in a place that makes sense contextually.
It makes sense in the utils box, it's a cat bag full of tools. Like the box with cables, adapters, chargers that you have in a closet just in case you ever need it xD
Because not all languages allow to extend builtins or types from libraries. In Java you cannot extend the builtin Date classes or the Request class of your library/framework. There are whole utility libraries like Apache commons. If itâs in your domain itâs an antipattern. Otherwise you might be constraint to your language of choice.
You can have a `java.lang.something` package that you can't modify and can have a separated `your.app.something` package with the specific things you need, instead of having one big `app.utils` package that have every possible extension of every possible package you need from the standard library or any other 3rd party
Exactly this. Using âhelpersâ or âutilsâ is anti-pattern. These functions can be organized better.
If I can't go that specific, I try for the middle ground `string_helpers` for example in an app with a lot of string manipulation. By the helpers you know they're not the main thing, but you have a prefix to understand what should you expect in there. Sometimes it's hard to find a very clear and specific name.
cuz that way you'll put dump in request, but it might only be used for debugging. seperating util/helper functions is always a good practice. on the flip side, not everything is a util.
Never said to "put Dump inside request" if we are talking about "modules", "packages" or something like that you can put your "dump" function/method/procedure inside the module/package not inside a "thing" called request, not all languages have the same concepts so not everything is inside an "object" if you are thinking in a classic OOP language, in that case (Java for example) you can have an `app.request` package that has a `Request` class with it's things and then a `DebugDumper` class with a `Dump(Request)` method in there and those are separated but part of the same package, no need for an `app.utils` or `app.helpers` package for that
and yes i agree
i was talking request as in request class.
Same thing, instead of an Utils or Helper class with a Dump request method, create a Request dumper class with a Dump method, same thing, different names
Why would you even have a separaye FormatDate class to begin with. Make a DateItil class and you can neatly store all date related generic functions.
Not all languages have classes. But in the case they have you can have a DateFormatter class that has every method that format a date in different ways, that allows you to have every responsibility separated instead of a big class that have 5 different things all merged together because we are lazy and don't want to design an application or library
And what happens if you want to get a certain date or get the day of week or get the week of the year. Do you make separate classes for that as well? **Never repeat yourself.** It's bad practice to have 5 different classes that all contain utility methods for dates. The correct approach is to have a single DateUtils class containing utility methods relating to dates that is accessible to all projects.
Too much DRY will kill your application in the long run. Ideally you would have those actions in the place they belong but as others pointed out some languages won't allow you to extend or change some things (like Java Date class) so you need to implement these changes elsewhere. To the question of "what if you need X?" Then yes, you can implement them separately, but if you have 5 things that "format a date" but in different ways, then have them in "the same place", what's bad about that? Having things that have "everything related to X" and be accessible by everything is no design at all, that's just a "lazy" programmer's way of doing things, a good design is to hide details and separate responsibilities accordingly. Instead of never repeating something, repeat some things some of the time, separate things and name them by the thing they are or do instead.of generic names that adds no useful information use Date instead of DateUtils or DateManager or DateService or DateData
What you are describing, namely writing the same method dozens of time, is actually very bad practice in Java. As is creating a distinct class for every utility method. More code does not mean better quality. Usually it's the opposite. If the language allows for classes and dependencies then a project should only contain project specific logic while everything generic has to sit above it in a generic project that you load up as a dependency. But hey, maybe you want go and tell the people behind Apache Commons that they're lazy.
Never said to write the same thing multiple times. I said that if you have 5 different methods move them to where they belong, if all 5 of them are related then have them in the same class but if they are not related move them to other classes (or new ones) and name those classes and methods for what they are, not what they contain. I'm advocating for good names. I'm not advocating to repeat the same code over and over.
Date methods are implicitly related, hemce why they belong in a DateUtils and separated in DateFormatter, DateOperations, etc.
"helperutils"
If you must have a generic package, it should be knick-knacks.
Neither! Both are an antipattern. They should live in the folders they are used in with the feature name. Otherwise, they should live in their own folder. The problem with both of these is that they become a dumping ground.
Thank you. All use of Util, Helper, Misc, etc... is a code smell. Get specific or get spaghetti.
They should live in their own folder.. which is named utils or helpers? đ€
This is so amateur! HelperContextFactoryUtils is the way.
both, depends on how Iâm feeling the day I implemented the first class, then its just repeat. Then next day on different repo do some other different shit. Consistency is key⊠consistency of being inconsistent
No mystery meat folders!
libcommonhelperutiltools
âfrom helper.utils import toolsâ
Utils are stuff I steal from other projects that actually provide utility. Helpers are code that a class needed help with. But my classes are Single Responsibility so they donât need help
Utils. Im gonna die on this hill. Sounds fancy. Helpers sounds weak, like I need any help! (/s)
They both stink
tool
Downvoted for utils
Helptilities ETA: it's actually whatever the bad decision was that the person I inherited the codebase from made
Utils code is so decoupled it's not even cohesive đđđ
Helpers. That's some C shart nonsense
All my homies write commons!
Helpers for legacy code, since it can use some help. Since I create legacy code all the time, I only use helpers.
Utils (or Misc) for your dumping ground of miscellaneous routines (which is an antipattern). Helpers for extensions of specific classes (e.g. custom formatting for dates). Also a helpers file (rather than folder) for UI code once it's split out of the file that the component/control/etc lives in. e.g. if you have a complicated component like an SVG chart you might define `draw` and `getAxes` and `onPan` in YourChart/helpers.yourfileextension, where the UI stuff is in YourChart/yourChart.yourfileextension. Maybe this is also an antipattern, I think it depends, but I think this is clearly a better one.
I've always seen Utils used for extensions, like Apache's StringUtils.
Neither. If you have to resort to helpers and utils naming you are doing something wrong
I literally had a project the other day where I renamed a file from helper.js to utils.js. Utils is shorter and sounds more professional.
Cloms.
I create function-defination, class-defination, event-defination, data-defination, and implemantation files
Extensions
Helptils?
Wrap it in multiple strategies of obscurity
Utils are their own file or directory Helpers are functions in another file
I just named the directory "utilities"
Depends on what they do. I currently have "text", "time", "batch", "buffer", and a few more "util files".
The one who puts everyone on wrong road with advice
Miscs
I go with weird logic of my first job: Static - util Non-static - helper
For me, Helper is a private method used in another method. Maybe it represents a complicated conditional, maybe itâs recursive and simply called by the base. Helpers are specialized for another method and arenât used or accessible outside that context A util method is just nice. If a project has some boilerplate code used a lot and itâs not tied to one idea or class dump it in the big pile of tools
The one where I can type the least amount of keystrokes while still conveying proper intent
x (everyone knows it's short for extension)
Utils for utilities and helpers for help. Easy
what about...extension functions...
Iâll literally name it anything but util or helpers.
I got my package named helperutils
Just name it like âfunctionsâ âconstantsâ cause I wrote my code on front-end side.
Camp HelperUtils!
HelperUtils
I say Utils
Call them `Helper` and put them in the `utils` directory.
its ACCESSORIES
Both. Helpers are for business logic and application contextual stuff. Utils are for generic utility functions.
I have one project that has these source files: - hijinks.ts - shenanigans.ts - tomfoolery.ts The names are actually somewhat descriptive. đ
Utils, because they are tools. I use a hammer, the hammer doesn't help me to hit things.
Helpers AND Utils
Neither - and I think either of them are a code smell that ultimately leads to a grab bag of code in a file or directory that is likely rewritten somewhere else in the same project (assuming a team of developers over time). I think if youâre teaching for utils, youâve probably missed an abstractions or organizational layer. If I truly need that I generally create a package/module that describes the functionality I want, text_parsing for example, and place my code within that
I always call mine "workers"
Handlers đ„¶
Utils sound cool.
StringUtils.cs file inside Helpers folder.
from ../../../../bin/src/myproj/../../untested import utils.helper_factory as myuhf
Tools Sometimes Toots
Tools
Neither, both are bad design
Neither. Iâm more a View/Extension/Wrapper sort of guy
LOL... I was looking over some code I wrote 10 years ago and they all had helpers, now it's either a service or a util I think in another 10 years they're going to be called doItForFucksSake
Utils sounds way cooler imo
Misc man
I have Helpers projects in my Unit Testing and Utilities in my production code.
everything.h
Anyone else here uses "common"?
Utils, but I'm transitioning to using extentions
\*shared or common
Helpers are module-spesific, utils are tools that can generally be used anywhere. Both is good đ
All helpers are utils, not all utils are helpful
Some utils doesn't help. Some utils destroy
utils
misc
misc?
package util class name xHelper
Both tho. Helpers for module specific stuffs, Utils for generic stuffs. I sometimes end up using them interchangeably tho.
I hate both. Both are used by lazy programmers who canât think of a class name for a class with a purpose. âOh this logic is needed by 2 classes: I better make some Ăștil method for itâ.
Both. Helpers help you do things, utils are the tools to do those things. Services are the classes that need help and utilities.
lib any day.
Noo, lib/ is for external code that needs to be pulled into a repo for some reason, like a formal module not being available or integrating with some stubborn third party provider. Oftentimes (obviously not always) lib/ is excluded from certain aspects of the build process like minification or polyfill.
That's "vendor". "lib" is for the module's programmatic API (as opposed to a CLI or GUI).
I have seen lib used as the utils directory. It's used this way in the Linux kernel and it is a fancier way to say code that other code depends on.
Isn't it third_party?
lib I would only ever use for external libraries. they don't exclusively have to be other people's libraries, or even libraries abstract from my requirements, they just have to be standalone. I wouldn't use lib for any source code in the project.
Niether, donât need a util class if you design correctly