0

I have been working on an Android application for some time, and ever since the beginning I've developed a practice of splitting my class's (mostly activity/fragment) code up into multiple files.

This is because the Udemy course from which I learned Android development had an instructor who followed this practice.

These files contain 1-2 functions, some of which are Kotlin extension functions and some of which are not.

Example:

enter image description here

I actually have kind of liked this practise, but at times I recognise the fact that it can be obsessive and overkill. This is because sometimes I even make new files for functions that have 1-2 lines of code.

I am posting this as I have received many complains from people that this practice I have is bad and is making the code hard to read.

I believe in the contrary, as it allows you to easily view commit logs for specified files/features, it makes it much easier to navigate between different functions, and having one big class with 5000 lines of code for me seems hard to read.

I am just posting this for feedback: is this a good practice? If not, what can I do instead?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
thebluepandabear
  • 101
  • 3
  • Do the benefits exceed the costs? – Robert Harvey May 21 '22 at 12:52
  • I think for me the benefits exceed it if it were this versus putting it all in one file, but I was wondering if there are alternative design patterns available that are better than what I am currently doing. Plus I am looking for feedback from others as to whether or not this is a good design pattern. – thebluepandabear May 21 '22 at 13:27
  • Are these functions all there to satisfy one or interface or abstract superclass, or multiple? In the Swift world, it's really common to use extensions to split up by protocol (akin to interfaces), not by singular method. – Alexander May 21 '22 at 13:42
  • You're right that "one big class with 5000 lines of code" is not good. I don't know if making it all extension functions is a good idea, rather then having actual distinct classes, each of which captures a well-defined concept, but I'm not very familiar with Kotlin. I wouldn't split by how many functions there is, but by how self contained the split is - could be 2-3 functions, could be 6, could be 12 (with a bias towards the lower numbers). "I have received many complains from people" - what people? Are we talking your teammates, or random people on the internet? – Filip Milovanović May 21 '22 at 13:46
  • (To Alex) Some are there to satisfy interfaces, but around 70 percent are not, but rather just regular functions. – thebluepandabear May 21 '22 at 13:46
  • @FilipMilovanović this guy who submitted a PR to my project complained about it – thebluepandabear May 21 '22 at 13:47
  • 3
    So, a random person on the internet. People will have opinions, and many of those opinions will be dogmatic. A lot of "standard practice" out there is not in use because it's particularly good, but for reasons like "it's easier to onboard newbie devs", or "this other company is doing it that way", or just plain cargo-culting. You're the owner of your project, you make the rules. It's a place for you to explore different approaches, search the design problem space. If you're going to change something, do it because you've found a better way to go about it, not because some guy said something. – Filip Milovanović May 21 '22 at 13:57

0 Answers0