Code modularity is not always a virtue

In most cases, code modularity prove to be good. It can boost development process and reduce code duplication. However, it isn't always good.

I remember seeing a post stating that coders should use other libraries that provided required functionality, even if it is just a single function that all they need. Do coders have to use a certain library just to use less than 10 percent of its functionality? I guess not. This approach is potentially dangerous and can create dependency hell. Unthoughtful dependencies would grow enormously and end up putting huge amount of code that the end-user doesn't even need. Imagine if you have to put six additional libraries in the map just to use a simple timer library! Therefore, I think it should be decided wisely whether to C&P existing libraries or write the code by themselves, depending on scale they need.

What is your opinion?

You just need to analyze the situation, would the library required be present in working maps? most of the time it's storage systems that are always imported onto a map, I don't think systems would suffer from this, only spells, because spells are complex and most of them require unique systems, which in turn would require storage systems.

What I suggest for the end user is to use compatible libraries, and then continue using compatibles only if possible. If most of your libraries depend on table, then get libraries that require it, thereby insuring a smaller and cleaner code.

I think it's the end-user's decisions that would give him dependency problems.

A simple timer library requiring 6 different libraries is poorly coded and needs to be re-written, bad implementation.

Usually systems/scripts revolve around a general theme or a general function. Having a library where only 10% of the code is needed seems like it would be a bad part in coding the original library. If the code is so dis-jointed that there is need for the other 90%, it should be split into two separate libraries.

I think as long as we understand the idea of a library and keep the stuff within a library uniform, we won't have this problem.

An example that comes to mind is the caster system and the new xe. The caster system developed into a monstrosity of a script. Sure, it had a lot of great stuff, but no one would ever need to use it all. Now with xe, one can add and subtract modules quickly and easily, filtering out all the libraries they don't need. This improve the modularity of the code and thus is a better candidate for future scripts to require.

Ammorth pretty much read my mind with his response. Code modularity when properly used is always the better way to go.

If you're only using 10% of a library, that library isn't modular enough.

I.E. what Ammorth and Rising_Dusk said.

Copy library as is as ever if you need only one function from it.

1) this wont slow down map
2) you always can pick other function from this library

I totally agree with your idea. I think your statement should be posted somewhere visible.


Agreed. It is true whenever done "properly".


I agree to you. BTW in an ideal world libraries are perfectly modular. However, it isn't always the case in the real world. There are libraries that are too complex, and libraries that was once ideal in aspect of modularity often become bigger and lose perfection for the sake of efficiency and ease of use (see Vexorian's ARGB; I'm not saying this library is bad). Also, putting just two functions with couple of lines and calling it a library can be lame.


1) the more code there is, it will. I know it won't be noticeable in most real-world cases, but I just mentioned for the sake of accuracy.
2) true, but using a library just to use H2I is ridiculous. In my opinion, what matters here are what the library is intended to be and what the user intends to do; if it contains H2I as part of similar set of functions, it could sometimes be fine, but sometimes not.


Well, I actually made this thread because I was concerned. Now I think I should have chosen a better title; ofc perfect code modularity can't be achieved in an imperfect, real world, but what's more important is people who make and use it.

As others have already pointed out, including a library and then only use 10% of it's functionality doesn't mean you have too much modularity, it means the library doesn't have enough of it.

This is a bad example because you shouldn't even be using H2I in general, the only place where you need it is storage systems and you only need one or two of those per map so it really makes no sense to make such a short function into a library when it's used in so few places.

But take for example another one-line function that could potentially be used by dozens of spells in a map; in this case, I'd say the modularization is warranted, though this is a borderline case.

Which is a total non-issue since the optimizer removes unused code anyway.

Not really.

ARGB is not really big, it is quite small, I dunno, come back three years ago, everything was huge then... It also does not matter anyway, the optimizer removes the unused code.

--
If you keep copies of functions embedded in your spells, in order to avoid code bloat from implementing a bigger library, here's what happens: The optimizer does not recognize duplicated code, so you'll end with more code bloat than when using the library, because the optimizer can recognize unused code...

ofc not. it's like you can use gamecache for anycase or use limited arrays cause you know it will be enough and not reach other the bounds.
aka it's all question of code design. modularity is good if you need to expand your "system" (or whatever).
all imo

I was a bit oblivious about the existence of such feature when I was writing. BTW what kind of optimizer is that? You mean the one comes with vJass compiler?

He means the one linked in his signature; Vexorian's Map Optimizer 4.7c.

And you know, if you get a library and only need 10% of it (take for example the old KaTTaNa's handle vars thing. It had a billion and one functions, most of which were never used, so I would just delete all the unneeded functions), get rid of the unused code yourself. Or, like Vex said 3 times, the Optimizer will do that for you.