Library Enhancement (separate each source code)

[jdevfullstack]

I just realized that the library is one big file, this will be problematic each time this file is modified.

Can we separate each source code as one file?

I think, this is the best we can do to avoid merge conflicts. For example, lines 5-10 is for a specific code, now two pull requests change the same file, in one pull request, the code was changed before lines 5-10, so now, the mentioned specific code 5-10 will be adjusted. The second pull request will have a merge conflict because of that.

And as you can see, if someone will use a specific code in that library, he/she will have a hard time finding all the specific imports for that specific source code, unlike when the source code is just one file, for example, a code for binary search, he/she can simple get it as one file.

[iluwatar]

I agree with that, we should separate each snippet into its own file to keep it manageable.

[jdevfullstack]

That way, its modular too, even though they are just snippets, they are still important on their own.

[grzesiekkedzior]

What you say for one source file for each section. Alghorithm class and its snippets, Array class ... For now we have 32 all snippets. I think it is more manage and simplier. One readme file and one source for section and tests.

[jdevfullstack]

Suppose a snippet will be downloaded by a user. It will be hard for the user to find all the imports because he/she does not have an idea what are the necessary packages. And it will be an overhead if you will just copy all the imports from that single file, right? That's the essence of one file per snippet.

When there are multiple pull requests, from time to time, the position of the snippets will change because each pull request is moving the same file, right? Unlike when there are several files, a pull request will just change one file not the entire library.

[grzesiekkedzior]

I agree with you and I understand it. This is good solution. But in my opinion it can lead to many files (only one method and one test for it) and too much fragmentation. This solution is extreme but good. Section solution is medium. Standalone file if is big can generate many problems with merge conflict and I've got one during this project.

It is not hard to find necessary and unnecessary package. This is not an argument for me.

[iluwatar]

@grzesiekkedzior are you proposing that instead of one file per snippet we would use one file per section? For example there would be one file for algorithms, one for array related things and so on? That is an improvement to the current situation as well.

[iluwatar]

If we stick with one README.md we are still going to have some potential merge problems. Although at the moment I don't see it as problem.

[grzesiekkedzior]

Exactly, one section per file and tests for it.

[jdevfullstack]

It is not hard to find necessary and unnecessary package. This is not an argument for me.

Do you have an experience in developing apps using SpringBoot? Then you'll realize how important what exactly the packages that are needed in a project. If you focus more on small projects, that's not a problem. But, when you are dealing with large scale projects then you need to be specific with the imports.

So, since this is actually about Java, why not we practice the things we are doing in real projects like being modular? Separating one large library into several files depending on the focus, much better if one file per one functionality, is a standard practice.

Again, at first, this will change almost everything, but once it's settled, this will be not hard to be maintained in the long run.

And lastly, this is your project. I am just suggesting.

[jdevfullstack]

Now, why not just create another folder that is for distribution for anyone interested in this library? And inside that library are the separate codes. This will not affect the build of your site, right?

[grzesiekkedzior]

Firstly this is not Spring project with millions lines of code, dependencies, library etc. Secondly I wrote that I agree with you and your solution. Thirdly I write about the same thing and I don't understand why you remind me constantly about modularity.

I think that we can create snippets like you suggest and put it inside packages. Packages names will be suggest the name of section and then we will avoid mess in files. This is what I want to pay attention.

[jdevfullstack]

Yup. Thanks. I also just want to help. I will discuss more ideas. There is a great potential with this project, maybe this will end up as big library of usable codes.

Others can also ask or assign me to review codes. I'm up to it. I've done a lot of projects in Java.

[iluwatar]

Good discussion and excellent points you have raised there. 👍🏻

It's also good to start thinking where we want to take this code repository in the long run. The original purpose was to create solid code snippets for people to browse and copy/paste. For this purpose the most important file is README.md and the Java codes behind it are just implementation details. Avoiding merge conflicts is the main reason in this case to separate the code into smaller files.

It's entirely another thing to develop a real code library that people include as a dependency. Personally I think it doesn't make much sense at this point, since we are small and not very special yet. But who knows what happens in the future - it's good to keep the options open.

[iluwatar]

@xdvrx1 I'd like to get you too onboard as a maintainer of this repository but usually I expect at least a couple of code contributions. If you're interested, then those are the steps. 🚶🏻‍♂️

[jdevfullstack]

I'll try my best to find time working with this project. Unfortunately, I have another job, I can be a collaborator but I can't be a maintainer.

[iluwatar]

Collaborator, that's what I meant to say ☺️

[stale]

This issue has been automatically marked as stale because it has not had recent activity. The issue will be unassigned if no further activity occurs. Thank you for your contributions.