Item 54: Use native methods judiciously
Disadvantages of native methods:
Use as little native code as possible
Strive to write good programs rather than fast ones
Strive to avoid design decisions that limit performance
Consider the performance consequences of your API design decisions
Don’t warp API to achieve good performance
Measure performance before and after each attempted optimization
Java doesn’t have a strong performance model
Item 56: Adhere to generally accepted naming conventions
Packages
Classes and interfaces
Method and field names
Local variable
Type parameter names
50.31K
Категория: ПрограммированиеПрограммирование

Use native methods judiciously. (Item 54,55,56)

1. Item 54: Use native methods judiciously

2. Disadvantages of native methods:

• Not save –
memory corruption errors may occur
• Platform dependent –
native methods are less portable
• More difficulties with debugging
• Worse performance doing a small amount of work –
consume some resources for going into and out of native code

3. Use as little native code as possible

4. Strive to write good programs rather than fast ones

Don’t sacrifice sound architectural principles for performance

5. Strive to avoid design decisions that limit performance

Components interacting between modules and with the outside world
are difficult to change.

6. Consider the performance consequences of your API design decisions

• Mutable public class – may require a lot of needles defensive coping
• Inheritance – ties class with its parent and may have limits on the
performance of superclass
• Interfaces – allow to create faster implementation in the future

7. Don’t warp API to achieve good performance

Problems with performance may go away in future releases,
bad API – never

8. Measure performance before and after each attempted optimization

Effect can be measurable or even negative

9. Java doesn’t have a strong performance model

There is a gap between
what the programmer writes
and
what the CPU executes

10. Item 56: Adhere to generally accepted naming conventions

11. Packages

• Components of package names should consist of lowercase
alphabetic characters and, rarely digits.
• Components should be short, generally eight or fewer characters.
• Meaningful abbreviations are encouraged
(For example, util rather than utilities)

12. Classes and interfaces

• Abbreviations are to be avoided, except for acronyms and certain
common abbreviations like max and min.
• Acronyms can be either uppercase or have only their first letter
capitalized
(The second is better. HTTPURL or HttpUrl)

13. Method and field names

• The same as classes’ names but the firstLetterShouldBeLowercase.
• If constant – UPPERCASE_WORDS_SEPARETED_WITH_UNDERSCORE

14. Local variable

• The same as members’ names but abbreviations are available

15. Type parameter names

• T for an arbitrary type
• E for the element type of a collection
• K and V for the key and value types of a map
• X for an exception
• A sequence of arbitrary types can be T, U, V or T1, T2, T3.
English     Русский Правила