In this lesson, we are going to be talking about project and code guidelines and we are going to be
following this report and read guidelines, which is pretty common, is pretty well known.
You might have already heard of it.
Now, why do we need guidelines and code styling?
They are really important because when you work in a team, it allows you to have consistent code styling,
consistent code within the project or maybe within multiple projects.
So it's easier to jump from one project to another because the code is has the same structure seems
already similar.
So this already applies to the project itself that you are working on.
So you want to have the same style in the project that you are working on.
You don't want part of it to have a certain style, a certain guideline and maybe another part to have
a different guideline or maybe no guideline, because it's going to be difficult for you to jump between
features.
And the same applies to different projects.
So in a team, when you have the same guideline and the same style of the code, this really simplifies
the way that you work.
It really saves a lot of time in the projects that you are going to be switching are already going to
seem familiar to you.
Now we have this guideline from Raybert here and we are going to skim really quickly through it.
And what I really recommend you to do is basically at the end of this lecture, take this.
You are, I'm going to say within the project resources so you can find it and reread again the guidelines
and the code starting and just go through it again on your own terms and try to make it for yourself,
which of them you want to follow, which of them you don't want to follow, because as you will see,
we won't be actually talking about all of them.
There are some that are really important.
There are some that I really don't consider to be that important.
So it's really important for you to take this with a grain of salt and try to analyze and decide for
yourself which of these are really going to be your guideline, your coding style.
And once you have such a style, once you have such a guideline, you can also internalize it and add
it to your company, to your own colleagues and share this with them.
Now, of course, if you have already a guideline, I still recommend you having a quick look.
Maybe you find out some new stuff.
Also, you'll see that the guideline has Android and Java references.
But even if you're using Kotlin, I still recommend you going into these guidelines because most of
them still apply to codling.
There will be just some minor exceptions.
Now, without further ado, let's go into it and let's have a quick look.
Let's just skim through them and see which of them really seem important.
Now, of course, that the class file is kind of on Android or Java one, the one you want to use,
the upper Kemel case convention here for classes.
I think that this is decent enough and you should do it wherever you can.
That's really important.
Now for resources false.
You should use the underscore and having all the time lowercase.
That's pretty important and decent.
And I guess that most of us already do such a convention.
Now for drawable, this is really important because I've had projects with a lot of drawable, with
a lot of assets, and they used to have different names.
They didn't have a convention.
So if you have, for example, a bot and you want all your troubles and assets to start with, but unlike
this, if you have an icon, you want all of them to start with icon doing so, your resources are going
to look much more organized and is going to be much easier for you to find an asset and to identify
by type that asset is.
So this applies to all types like menu tabs and so on, but is a really good rule of thumb to follow
such a style because you will find resources easier now going to conventions for icons.
This is again pretty similar.
Or for example, if you're using and restore, it will automatically generate this kind of stalling
for you.
But still, if you are importing them for projects like from an external resource, you should make
sure that you have some kind of styling for the naming.
For example, the icons always start with icon and an underscore.
And you can see here we have an example now for Selecter states, this is pretty important as well.
It's easy to for you to identify which is which state is which.
And you have all of these certain states here and all of these examples and maybe you can identify and
implement this in your project as well.
Now, going to the OUTFALLS, this, again, if you generate activities or fragments with Android studio,
with that, we saw that it has you're going to probably end up with these maimings here and also for
the activity itself.
And you won't have to really take this into account.
But if you create the layouts by yourself, you want to make sure that the activity starts with activity
in the cloud for the fragments.
That fragment is just a general rule of thumb to follow this kind of convention.
Now, let's go and skip these menu files for now.
There is a very important rule here, and that is the.
Ignore exceptions, and this kind of idea is pretty similar to what I've told you about trying to let
the application crash, so we had a discussion about the liability.
And in case you have a variable that shouldn't be known, but it is no, you should let the app crash
so you can find the problem, the bug, so you can fail fast.
Now, this is something similar, not the same, but it's similar in terms of you should never, like,
catch an exception and don't do anything with it.
You should have some kind of logic.
So even an exception has been thrown.
Well, something has gone wrong.
You've probably tried to pass along a value and you need to do something.
You can either send the report.
You can either recover from this point that this is important because it allows your product to recover
from errors.
If you hide them by doing nothing like we can see in these brackets here, Will is not very nice because
you don't know that the app has recovered.
It is going to stay or some kind of grey area state.
So as a good rule of thumb, you should try to do this and not ignore exceptions like this one is pretty
important, as you can see here.
And this explanation tells you that you might be creating mine codes for your code and in case someone
trips over them at some point, it will be pretty nasty.
Again, this is something similar with what I told you about the noble values.
All right.
The same goes for generic exceptions.
So if you have multiple pieces of code, it's easy for you to just wrap them in one, try, catch and
have a generic exception.
But this is not a very good idea because you will never know in this block here will actually handle
the error.
You don't know which was the source of the error.
So you don't know if the source was this IO function, if it was this parsing function or a security
function.
So you want to make sure that you catch each exception individually so you can have a handling system
of handling case for each type of exception.
Now, let's go a bit and skip the qualifiers because the imports are usually done automatically by Andres
studio.
So I don't want to spend too much time on this.
We are going to have a quick look at style rules for Java.
And again, if you're in, there are still some of these that still apply.
I don't want to go into Hungarian notation for private variables at the end.
I don't like that.
So basically that is a non-starter field.
But this has been described by Google and I wouldn't really go with this.
What it's still important if you have static final constants like in the companion object of the codling
analogy you can have, you're going to make sure that you want to have all caps and underscores for
Konstanz.
Now, let's keep this for a bit and get these acronyms as words chapter, because this is really important.
I've seen this done many times.
You have these kind of acronyms here like you are.
All right.
You do not want to do this if you do this.
Well, we kind of violates the whole Kanakis convention for the variables.
You don't want to do that, right?
You want to have like this as the word.
You want to treat it as a word.
Example, the customer ID, we know that this is an acronym, but in code, you shouldn't treat it as
an acronym because you can end up with something like this.
I mean, if I see this in my code as a variable, I'm surely going to discard it.
I don't really want to see that this kind of variable in my code.
So what good rule of thumb is to treat acronyms as words?
Now, regarding the spaces, I wouldn't really spend too much time on this because unrooted are already
kind of takes care of that.
If you use the shortcut for the formatting that I told you about in a previous lesson.
Now, going into the brain style, again, this is something that is more or less important.
For example, they argue here that this is a bad way of actually having the conditions.
I mean, the culture can be on a separate line if it has only one line.
I personally disagree with this.
I find this much more readable than this.
But again, this is to your own personal taste.
This is something subjective.
I wouldn't make a guideline out of this.
You should probably agree with your colleagues who yourself to each one of them you're going to use.
Now, go into annotations.
This is pretty important if you're using Dagar, for example.
So any kind of dependency injection framework, it might have some annotations and you'll see that your
class might have multiple annotations.
And you want to make sure that if you have annotations, multiple annotations for a class, you want
to place them on separate lines like this so they're more readable.
Now, if you have a variable with several annotations like this one here, the data manager.
You can actually inline them like this is fine, it's it's OK, it's a bit different from the class,
but again, this is not that important.
I wouldn't really treat this as a golden rule now going into the actual more important stuff.
So let's keep that logging guidelines that are important.
But I would not spend too much time on that.
I want to get here to a very important piece, and that is class member Audrey and I have to talk to
you about this already.
And I hope that you have already got the gist of it.
Now, we are going to be talking a bit more in detail.
As you can see, we have some kind of ordering.
And by having such ordering for the components of a class, you can create a consistent structure for
all your classes.
And if you do so, you kind of transform all your classes into something familiar is going to be easier
for you to jump into new classes.
You are going to know where to look for a constant, where to look for a constructor, where you look
for possible methods.
So you know that private methods are going to be at the bottom of the class.
The constants and the fields should be at the top of the class.
And so that's really a really good idea.
If you have them mixed up in several classes as well as a developer, you might end up having to read
all the classes, all the content of the classes.
And it's just better to have this kind of preparedness for knowing where the actual components are within
a class.
And as you remember, first should be the constants, then the fields, the constructors and then the
Ofri methods and callbacks.
And only after that you have the public methods, the private methods and the classes or interfaces.
So if you follow such a rule, that's great.
You can actually automate this with Andrew if you spend a bit of time.
But if you do this, we have an example here, you will end up with more consistent code within your
classes, and that's a very good thing.
Now, this example doesn't really provide all of those components here, but it's an idea.
I think you have the entry lifecycle first as an over in the method, the fields here, which are the
first and like the priority, which is the content itself.
And only after those you get the private methods and classes.
Now, there is something really important and right.
At least you have an activities or fragments.
You have the lifecycle callbacks.
Right.
And you want to treat those in order.
So if you're in your activity here, you have multiple lifecycle callbacks.
You want to have them ordered in the order that they really come from the system.
So we know the end result on is that we should know the order of these callbacks.
We know that uncreate should be triggered before on a resume and on pause before resume and on.
These should be the last one.
So you should basically stick with the actual order that they are called by the system.
And this allows you to have a more linear idea.
And what happens within the code?
You know that the code within the uncreate here is going to be executed first and then the resume code
and then John Paul's and then the undestroyed.
So that's a very good rule of thumb.
I really recommend you do this.
And again, these are overridden methods.
They should be first before public or private methods that there's something really important in the
parameter ordering for Android.
At least you want to make sure that the first parameter in a method in the list of parameters, as we
can have here, is the context.
And the last should be the callback.
Now, of course, that sometimes you won't have them, but if you have them, try to make sure to have
the context first because it's pretty important.
And the callback last because you might be using trailing lambdas on codling.
And so now let's also take a quick look at Konstanz naming and values, because this chapter here is
important.
It allows you to kind of conceptualize how to name your constants.
And in big projects, you are going to have a lot of constants.
You're going to have constants for Bundall, for intent, for extra, for arguments, for preferences.
And if you follow a prefix, a custom prefix like we can see here is going to be really easy for you
to understand in the code which constant you should use and where you can look for them.
We have an example here.
As you can see, that's fine.
Now, something that, again, is important is related to the arguments of fragments and activities,
of course, that for an activity you should pass the intent in which you can actually start the activity
so you can use the Internet to start a new activity.
He should want to make sure that the intent is extracted to a separate method.
So I would honestly go in the activity, create a static method like this one and have a great sort
intent here and pass all the intent parameters that they want as parameters here.
And by doing so, you kind of externalize the content creation for this activity.
So in order to launch it, you need several parameters sent.
Instead of having this code copy pasted wherever you need to launch that activity, you can have it
already has a static method in the activity in one place, and that's just much better now for fragments.
It's pretty similar, but you also have an advantage.
You can actually return an instance of the fragment.
So what you can do, you can create in the foreground class a static method like an.
You see here called new instance I actually use this is really useful and pass all the parameters that
that fragment needs in order to display.
So as you can see here, we pass them, we create the fragment.
And by having such a static method, you can make sure that all the other pieces in your app called
this new instance static method.
And you don't have I don't know, maybe somebody's trying to pass only one or two arguments.
So if they use the new method, you can make a discipline out of this.
You can make sure that the fragment will be always instantiated with the correct argument.
Now, let's go a bit at the line length.
We know that we don't want to have them over one hundred characters.
Well, that's already highlighted by another studio, so that's fine.
If we go here to line rewrapping again, this is fine, but if you factor code with a shortcut that
I've told you about, this is going to be automatic.
So we don't have to do it manually all the time.
But one last thing.
One of the last thing is this with a chain, if you remember, we had to do a lot of operations on this
and we use those called in collection operators and we change them.
Now, how we did we change them here like this one after another, as you can see, as we have this
Picasso example here, because it improves the.
Now, if you look at the counter example, which is this one here, or it doesn't make too much sense,
it's much harder to read while this one is much easier to read because you can see that you have one
action, second action for the action.
So I really recommend you to change these kind of operators on separate lines.
It makes the code much readable, even though you lose some code lines.
That's fine.
Now, the same with long parameters here.
If you have a method that takes a lot of parameters, I would actually suggest you try to limit the
number of parameters for a method.
If the method has 10 parameters or actually over four or five parameters, that's a sign that maybe
you should encapsulate that data in a special class, in a special holder.
But let's say that you have such a method for some reason, and it would be a better idea to basically
break all the parameters on separate lines like this Leadbeater method here.
Does that really cool now going into the Java Change starting, which again, it tells you that you
should have the operators on a new line.
That's basically the same thing that we did for cottin collection operators and is kind of an abstract
thing you can apply to wherever we have operators now, for example, style rules.
This is important because you don't want to go having for example, it takes you having a separate line
like this one.
It just doesn't really work that way.
It's easier for you to have a closing time like this one, and it's just much faster, less good for
you to actually maintain.
Now, going into resource maimings, this is interesting because this doesn't apply to cottoning.
Now, if you have Java in your project, in your code, you might be getting the views which defines
you by IDE method, which is pretty common.
So you can use these prefixes, which are really good to have a uniform.
Isen in terms of view naming, as you can see here, if you have an image, you you start with the image
prefix.
If you have a text to start with a text with a button like this.
And so but if you have Kosslyn in your code, I don't really recommend you doing so.
I recommend you going into an actual Kemel case approach.
So instead of having image underscore Profar with a small letter like this one, you should just imagine
a capital letter B and then Profar.
So you should basically just follow the actual variable convention that you have because you will be
accessing the views with codling synthetic.
So you're not going to be using Coplin find Ubaidi.
That's just not going to help you.
You should use a synthetic and just reference the views directly in your code, your classes.
So that's just a gist of it.
This doesn't really apply to Cotliar now in strings.
Again, you should try to split the strings to have errors message title.
So you should do this kind of prefix to kind of have them in separate categories.
That's really going to be helpful for you.
And apart from attributes ordering, which is a more of a custom view importance, I would honestly
stick to what we discussed so far because this lesson has been already pretty long and we're not going
to talk about unitards right now.
I'm going to have a separate lesson on this.
And we're going to talk there about how to template your test names, as you can see here, and going
to have a more detailed explanation there.
So this has been pretty much everything now as recommended.
I would really urge you to go for this guideline again on your own and try to make for yourself which
of these rules are ready for you and which of them you really want to stick with, then have to stick
with all of them is just a guideline.
Of course, you don't have to really enforce all of them to be applied.