My Top 7 Clean Code Tips for Android Developers (You Can Immediately Apply These!)

Thanks for share. You covered good amount of tips in short video.

Well, my example of genius code is needed when I don't want to repeat myself.
Check this example:
if (prop == "something" || prop == "something_else" || prop == "anything") {}

you can shorten it to this:

if (listOf("something", "something_else", "anything").contains(prop)) {}

it's shorter and you avoid repeating yourself.

Please mention more about law of Demeter. From my work experience, there are a lot of incomplete codes using Clean Architecture and Util functions which break the the law of Demeter. Given repeating functions are found, what is the rule of thumb on when to categorize functions into UseCase and when to let functions alone as util function?

thankyou senior

Wow, one of my college teachers has already given me all of these tips😅

Looking at the law of Demeter, and I disagree.

This would make the code grow exponentially! For almost no reason some times.

Since you can't do A.B.C.method1(), you'd instead have B have all of its own methods, and a way to use all the needed methods of C, and if it has more objects, those too.

And if those objects also have more objects inside, that's even more code to write!

In the end you will either have multiple massive classes with all the methods in existence, or just avoid using objects altogether so you don't have to bother.

The idea is nice for layers of your code, but it's quite dangerous to say this will make better cleaner code

Edit: All right, one missing rule that I haven't seen anywhere

If B has C and changing C using it won't affect B's state, it's fair use. Now it's much more understandable

IF-ELSE is a grey area... there are equal arguments for avoiding ELSE and for avoiding early returns. This "philosophical debate" could last days. ;)

Thank you for this Video~ it's very worthfull~
Does Secret number 5 ( Follow the Law of Demeter ) means the "Capsulation"?

I would also like to add that you should avoid adding different logic code in one function. For example you have calculateDistance(), it should only contains logic related to its name and don't add irrelevant logic like conversion and etc. It should be a separate function.

thank you

I agreed with all the points but about comments. I guess people should add comments what they feel like it's totally subjective.. your code might read by someone who just started learning things few says ago...also it effect dev performance..he/she has to think about what should be the comment.. comments should be natural...it can be improved later...when you code focus on logic .

좋아연

Can you please a official linkdin page for plcoding ... it will help us to link the certification of plcoding to link

very good one, the last tip i thought i was a weirdo cause i use it a lot.

Hey Phillip
Can you make a video on new project level gradle model
I am little bit confused about adding classpath and other thing in it

Bro make detail video on foreground service restrictions . Foreground services are being killed by os

Thanks! I just found your channel and with you I learn good practices and English at the same time, my day to day I use patterns, refactoring and smell codes, it would be interesting if you made more content of good practices. No matter how much you know a language or SDK (Android), the next level as a programmer is this.

Many thankssssssssssssss

hi Philipp , could you make a video explaining some of Google's architecture sample apps ? I tried to look into those but it was not that straightforward. Thank you!

In the last section of the video, you can actually remove the {} associated with the "if" statement and make it a one liner:
if (isActive) return

I bought both of your courses and I'm learning so much. You are a huge help! A video about Entry forms would be great (like a bunch of titles with matching edit text fields) I'm struggling to grasp the concept of Lazy column/ RecyclerView with this scenario. Either way, thank YOU!

That's exactly what i am going through thanks

Hi, thanks 👍
Can you explain why putting the "else" code out of a else statement after a return is better?
I know the concept and I understand why it is not necessary, but like you said it another tip, readability is important, and scoping it inside of blocks looks more readable for me, especially if there's more than one return statement.

Good stuff big 🐕. Agreed with all of them.

I've been doing software development professionally since shortly after college, so about 15 years, and I've seen most of those often. The pointless comments and crappy variable/class/function names the most often. There's no good reason not to have descriptive (reasonably so) names for things; abbreviating things and making names like 6 characters long is just unnecessary and makes maintainability more difficult. Heck I even didn't do that at a previous job where I did a fair amount of VB6 coding (shudder), where there was no Intellisense (although you could press Tab to autocomplete names if they were already correct iirc, it was a good check).

You have definitely well studied "Clean Code" by uncle Bob 😉

nice video, could you please share an example of testing android project with clean architecture i am having difficulties to understand how to test viewmodels , test cases and the view with states and events

hey Philipp ,,,, I wanted to learn android dev.. from your course ..but now I am facing problems ... My request is: could you make a video on " BUTTON" again .. because when I am doing ACC. to your previous videos I get errors ... believe me I saw many tutorials on that but I am facing so errors .again and again...... please please please make a fresh video on buttons.

Love the videos.
I love coding.

To be honest the "Rule of Three" is a trap, it is nice to not repeat yourself, but now let's imagine a case where you have refactored the code to not repeat yourself, and let's say that you have like 5 occurrences of your code that you replace with some kind of base class of whatever, now let's imagine that you need to change the behavior but only in one of your occurrence, but you have extracted this code to a single shared piece of code, so you either need to give up on using this shared code for this occurrence or use some kind of flag or whatever passed to this base code, okay, you've got it done, now you need to again change the behavior of another occurrence, but only this one, now you're in the same situation like before, and it becomes messy as hell

Overall the awareness of not repeating yourself is good, but forcing it to not repeat yourself actually makes the possibility of changes really limited and error-prone

The rule of three is a trap. I've had to unravel and split code in my job in order to implement new features and it is not a fun time. The rule of three is nice, but shouldn't be preferred over modularity, especially if you are working on a big app.

7 tip - it has unofficial name of "return early pattern" :)
3 tip - I agree with third tip about long name, but i can't completely agree with the example you show there. For me it is okey to have function like findPerson(name:String), because param name inside braces says itself about condition. Also such naming as findPersonByName downgrades possibilities of using methods overload which is really nice feature to have, where you have findPerson(name: String), findPerson(id: Int), etc.

How were you able to drag and drop lines of code from one block to another in your last tip?

🧐🧐🧐🧐👌👌👌

Love the tips

genius boy, still uploading videos, Even though he is traveling south africa, what a boy

So side-effect = bad, but it's a feature in compose?

very cool video thank you bro👍👍👍👍

love you

Well done - You have interesting names for some of these rules. I didn't know 'field encapsulation' was called the law of demeter.

I strongly disagree with the last tip. Weather to use return or else should not be determined by the subjective way you find more readable, but by being as close as possible of the way of thinking of the product owner of the software, and 99% percent of the time else is the appropriate choice.

I don't quite agree with the last one. For slightly larger functions it's common to overlook return statement. However a else block makes it more readable. When a developer skims through a function the indentation + block helps developer achieve better readability.

When will you post Android News video?

Slightly different version of findByPersonName :

fun findPersonBy(name: String): Person?
findPersonBy(name = "Philip")

I totally disagree with you in the last tip because it breaks the law of symmetry 🥶🥶🥶🥶🥶🥶🥶🥶🥶🥶🥶🥶🥶🥶🥶🥶

What theme are you using in Android Studio?

I like the Rule of Three. I've been doing that intuitively