Android optimized code code writing habits Code normalization

Today I want to talk about code habits:

When I first started to learn Android, I believe that many novice people will have a question, we as a rookie in addition to the technical shortcomings in the end what is not the big God? Believe that the novice to ask this question, it must be a person who does not admit defeat (not to be called Angry Green, I recognize

For the angry Green seems to be a derogatory) so like to ask questions, but some experienced big God sometimes will say himself Baidu, not Google, so simple question also ask! This may hurt us a lot, but quite often it is

It's up to us to find our own research, in fact, as a rookie does not like to do their own writing, just want to have a shortcut standing on the shoulders of giants, but the fact is not so because all the problems to remember more solid, clearer

Understand, really need to find themselves, their own research although this may take some time, but it is valuable, okay, so much to say about the topic of how to optimize the code code writing Habits Code normalization:

The first is the name, this I have deep experience, is always said by other members of the company,

Comments:

Developing good annotation habits has great benefits for improving your programming skills and teamwork skills .

• Do not use pinyin naming (English is not good can be translated by Youdao, but avoid pinyin)

• Names should be concise and descriptive, use full words, avoid abbreviations (unless the abbreviation is used more broadly, such as URLs, HTML)

• Do not appear in the code in Chinese punctuation characters, for example: ', ', ': '

• Notes can be written in Chinese punctuation characters for easy reading

• Note Follow English writing habits, English punctuation after a blank, to avoid the tight sentence

• The letters of color values must all be uppercase

1. Package naming

The package name consists of lowercase letters, which begin with the default, followed by the com.example.android module names that are broken down by functionality. (In this middle we are usually named after the company name)

2. Class and interface naming

The first letter of the name needs to be capitalized, and if it consists of multiple words, the first letter of each word needs to be capitalized and the other letters lowercase.

3. Naming the method

It is named by the Hump naming method. (This is best known, let others know you this method is probably what)

4. Naming of variables

Named by the Hump nomenclature. (now this variable name Google gave a small specification, is the front of M)

• Non-public, non-static domain variables are prefixed with M
• Static domain variable with s prefix
• A variable of a collection type uses a plural form, and if a variable of a variety of collection types stores an object of the same type, it can be easily distinguished by a collection type, except by function.

5. The name of the ID (this estimate many students will name this very important, to see the code later, so this to remember)the words that make up the names must all be lowercase, the words are separated by underscores, the names do not require complex hierarchical positioning, only the functions of the controls that are represented can be accurately described, and usually we use the abbreviation prefixes of the control type before the name to avoid the hassle of repeating the naming.

6. Naming the constants

Constants need to be declared in final static form, and the words that make up the names must all be capitalized and the words separated by underscores.

Let's talk about some of the benefits of reading and code specification in the process of writing code:

For example, we often use in the use of:

Android:text= "OK"

In fact, it is very convenient to write, but for the program and coding problems are not convenient Google's official advice is to write:

android:text= "@string/main_table" (Put the field in a string, so it is said to speed up the compilation speed, specifically I did not test ...) ）

There are a lot of controls in the XML file, many of which have the same properties, many of which do not use the Style property at first:

For many controls that have the same properties, we can write this

              <radiobutton                android:id= "@+id/rb_main_table"                style= "@style/main_radiobtn_style"                android:checked = "true"                android:text= "@string/main_table"/>            <radiobutton                android:id= "@+id/rb_main_total"                style= "@style/main_radiobtn_style"                android:text= "@string/main_total"/>

To seal some attributes into the style:

<style name= "Main_radiobtn_style" >        <item name= "Android:layout_width" >fill_parent</item>        <item name= "Android:layout_height" > @dimen/activity_main_radiogroup_height</item>        <item Name= "Android:background" > @color/menu_radiobutton_bgcolor_selector</item>        <item name= "Android: Button "> @null </item>        <item name=" android:drawablepadding ">4dp</item>        <item name= "Android:textcolor" > @color/menu_radiobutton_textcolor_selector</item>        <item name= "Android: TextSize "> @dimen/normal_textsize</item>    </style>

There is a way to see their own writing, that is sometimes in the code in a method has a lot of algorithms. Declaration. Plus monitoring what, using adapter and the like, we can put, theseextracted into a method, put it in a method, such asThe adapter class is drawn out and placed in a single class,The code written in this way does not have too much in one class and makes people look dazzling. There are many methods that can be extracted separately and put into a class, so the code is much more concise.

There are some times we may use Viewpager, and AddView if the view is more, this will result in a class of code in particular, a variety of processing, looks not good, this time we can use fragment to replace the view, I have written before , that is, you can slide the fragment in this is a very good package, save a lot of things,

At the end of the long-winded, is that there is time to see more, more hands-on practice, the last Baidu Google has no answer in looking for the big God asked Ha!

Which students have better we can exchange together, above only represents my personal views and suggestions

Android optimized code code writing habits Code normalization