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

[@codinginflow]

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

[@wealthynerd9943]

You always the first one who comment in every single video, and that's great actually. If you already have a great channel ☺️

[@punerealestatebuilder]

Bhai itne comment kr ke kya kroge?

[@Another0neTime]

Father

[@xpopcornx1747]

Depends on what the 3 are. You should never duplicate 20 lines of code.

[@bty_s]

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.

[@marksunghunpark]

I think #3 might go well with Inline class in your case: findPerson(name: PersonName) findPerson(id: PersonId) PersonName and Person even could have both same type as their properties. value class PersonName(val name: String) value class PersonId(val id: String) Alternatively, we can use sealed class as well. findPerson(param: FindPersonParam) sealed class FindPersonParam { data class ByName(val name: String): FindPersonParam() data class ById(val id: String): FindPersonParam() } In this case, findPerson could call findPersonByName and findPersonById internally. Anyway, there are different options and they are all depending on context.

[@robertstarke7134]

i only know nr 7 as guard clause (en.wikipedia.org/wiki/Guard_(computer_science) )

[@AbdulelahAGR]

I wish you were there 4 years ago when I was still new programmer. Your content would've saved me learning things the hard way and would save me from some KZbinr how just give wrong information. It is only a matter of time before you become one of the best recognized KZbinrs in the android dev community. Good luck

[@jeepaholic326]

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!

[@PhilippLackner]

Thank you! Glad it helps :)

[@tadeogonzalezalvarez6488]

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.

[@buszi_]

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

[@pinoy_marites_beh]

it becomes a trap when inheritance is used in a dogmatic way and when you want to consolidate functionality. I'm actually dealing with this thing you mentioned and I am so trapped with an inheritance of our project where I need to inherit a functionality that are context/lifecycle dependent making all my UI layer littered with the same function calls from that inherited functionality. I wanted to detach my module from that inheritance and delegate that functionality somewhere else but unfortunately its a big big big implementation. So one thing I learned from this and practicing now is, when I refactor and/or consolidate functionalities for this "Rule of 3", I have to ask my self 2 things, first is, am I gonna need it(YAGNI)?, to answer my first question, my second would be, what are the most probable or better be, inevitable situation(e.g coming from requirements and culture from my work) that will make this "consolidation" choke the dependents, implementors or children in the long run. So I have this "trade-off", "redundancy" mind-set for an open-ended possibilities. Basically if I feel like it will choke something in the future, then its better to stop using inheritance for this "Rule of 3" principle as much as possible. People often times don't realize the "S" in SOLID is breakable by inheritance.

[@PawanGupta6186]

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

[@riyupapa39]

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

[@clamum9648]

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).

[@kimcherwoo]

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!

[@larrystreehouse1124]

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?

[@AliasdHacker]

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

[@AliasdHacker]

Also, this is a variable name I made... sometimes I take it too far. addOnOptionIsPriceSameAllSizes

[@r_yan3531]

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

[@ciach0_]

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.

[@baselnat93]

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

[@arfinhosain]

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

[@yayiiz]

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

[@yossimaskin1393]

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.

[@PhilippLackner]

It removes one indentation. Indentations make your code unreadable if there are too many

[@nicolasfelipe1]

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

[@masti437]

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

[@AhsanAli-vz6mg]

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

[@RanbirSingh-dl9co]

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 .

[@bitwisedevs469]

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.

[@jabrane1564]

Love the videos. I love coding.

[@mustafaammar551]

very cool video thank you bro👍👍👍👍

[@24035709]

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

[@petersuchanek5296]

Shift + Alt + Arrow

[@breensrobert]

Love the tips

[@user-cr9ky9bj2z]

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

[@dragosciupe2928]

What theme are you using in Android Studio?

[@CoderzF1]

looks like darcula

[@edgeeffect]

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

[@lasanbajrasandi8434]

thankyou senior

[@mrgriboman371]

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

[@tiltedbybox6118]

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

[@PhilippLackner]

It's not a feature in compose. Compose offers tools to deal with side effects

[@futsuchinpo9892]

thanks a lot !

[@John-qt6qk]

That's exactly what i am going through thanks

[@3realfacts]

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.

[@sudesh6807]

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.

[@bringoff]

If your function is that long you can't spot return statements there, that means something is wrong with the function and it can (and should) be split into multiple functions.

[@bringoff]

Also the less nesting inside the function, the easier it to read. And the "quit early" approach helps with that.

[@purplehazer417]

When will you post Android News video?

[@PhilippLackner]

Every first Wednesday of the month

[@milon27]

thank you

[@CookingWithMasterChef]

love you

[@danyelsh874]

Many thankssssssssssssss

[@marksunghunpark]

Slightly different version of findByPersonName : fun findPersonBy(name: String): Person? findPersonBy(name = "Philip")

[@PhilippLackner]

I wouldn't do that, since it forces you to use named parameters to make it readable. Also you wouldn't find this function by normal search if you search for findPersonByName

[@marksunghunpark]

@@PhilippLackner Yeah, thank for the point. I hope Kotlin would support inout parmater like in Swift.

[@illusion9423]

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

[@이성규-f6z]

좋아연

[@george_sigalas]

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.

[@defetron2754]

🧐🧐🧐🧐👌👌👌

[@tomwilliam7299]

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

[@marksunghunpark]

I +1 Philip with this because I don't need to read the rest part of the code if it does early-return. Can you please give me some explanation of the law of symmetry?

[@tomwilliam7299]

@@marksunghunpark kzbin.info/www/bejne/iXfZaYqjZ62XhK8

[@tomwilliam7299]

@@marksunghunpark also this: kzbin.info/www/bejne/jIfadIqujNFmpbM

[@marksunghunpark]

@@tomwilliam7299 Thanks for that. I will have a look.

[@luigisgl2639]

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.

[@samstoyroom]

Agree, it's more close to how human thinks.

[@bringoff]

How can the product owner affect my usage of some programming language expressions? 😀 Sounds pointless