Java_code_convention_ppt_report for group 1.pptx

this is a presentation about java code convention that we made

1. J A V A CODE CONVENTION Prepared by: Justin A. Abrasado BSCoE 1

2. After performing this report, the students should be able to : Know the code conventions of java Know how to properly arrange codes and comments Know the rules or guidelines for java OBJECTIVES

3. TABLE OF CONTENTS Introduction 01 File Names 02 File Organization 03 Indention 04 Comments 05 Declarations 06 07 Statements 08 White Space 09 N a ming Conventions 10 Programming Practices

4. 01 INTRODUCTION

5. Why have Code Conventions ? Code conventions improve the readability of the software. This allows engineers to understand new code more quickly and thoroughly. Coding conventions are a set of rules or guidelines for a particular programming language What are Code Conventions?

6. 02 File Names

7. File Suffixes This table below are the lists of the file suffixes used by Java software. Suffix File Type .java Java source .class Java bytecode .jar Java archive File Names This table below are the lists of the file suffixes used by Java software. File Name Use Makefile Preferred name for makefiles. README Preferred name for the file that summarizes the contents of a particular directory.

8. 03 File Organization

9. Block placement on the storage media is referred to as file organization , which describes how the records are stored. Avoid working with files that are more than 2000 lines long.

10. Java Source Files Java source files have the following ordering . Header comments. package and import statements. class and interface declarations.

11. Header Comments Every source file should have a C-style block comment (/*...*/) at the top that includes information like the file name, and a copyright notice.

12. Packeage Import Statements Most Java source files begin with a non-comment line which is the package statement. Import statements may then be made. 

13. Class and Interface Declarations The structure below should be followed when making a class declaration (in order). Class documentation comment. Class declaration statement. Class implementation comment. Class implementation sections

14. 04 INDENTION

15. Line Length As a general principle, four spaces should be used to indent. It is unclear if the indentation should be made with spaces or tabs. There must be exactly 8 spaces between each tab (not 4) Lines longer than 80 characters should be avoided , Examples for documentation should have shorter line lengths, typically no more than 70 characters .

16. When an expression will not fit on a single line, break it according to these general principles: Break after a comma. Break before an operator. Never break, however, at the dot (.) operator Prefer higher-level breaks to lower-level breaks. Align the new line with the beginning of the expression at the same level on the previous line. If the above rules lead to confusing code or to code that is squished up against the right margin, simply indent one tab stop instead. Wrapping lines

17. 05 COMMENTS

18. The delimiter for implementation comments is //. Java also allows for the use of /*...*/; however, these conventions have standardized solely on //. Programs can have four styles of implementation comments: block, single-line, trailing, and for temporarily removing code . Implementation Comments

19. Block comments are used to explain files, methods, data structures, and algorithms. Block Comments

20. Short comments can be indented to the level of the code that follows on a single line. Single-line Comments

21. Admittedly short comments should be spaced far enough apart from the statements to avoid being on the same line as the code they describe Trailing Comments

22. A line can be commented out in full or in part using the // delimiter. The entire chunk of code can be commented out by using it in a series of lines. Temporarily Removing Code

23. One remark per class, interface, or member is placed inside the comment delimiters /**...*/ (notice the double asterisk (**) at the beginning). Documentation Comments

24. 06 Declatation

25. One Number Per Line One declaration per line is recommended Initialization All variables (local and class) should be initialized where they are declared.

26. Insert all local variable declarations at the beginning of method definitions. Placement The one exception to the placement rule is indexes of for loops which in Java can be declared in the for statement

27. Class and interface Declarations No space between a method name and the opening parenthesis (() starting its parameter list Opening brace ({) appears at the beginning of the line following the declaration statement. Closing brace (}) starts a line by itself indented to match its corresponding opening statement . The name of the class should appear as a trailing comment following the closing brace . Methods are separated by a single blank line.

28. 07 Statements

29. Simple Statements Each line should contain no more than one statement.

30. Compound Statements Compound statements are statements that contain lists of statements enclosed in braces ({}). Return Statements A return statement with a value should not use parentheses unless they make the value being returned more obvious in some way.

31. IF , IF-ELSE , IF ELSE-IF ELSE Statements FOR Statements WHILE Statements

32. SWITCH Statements DO-WHILE Statements

33. 08 White Space

34. Blank Lines By separating logically linked code sections with blank lines, code readability is improved . In the following situations, one blank line should always be utilized. Between class and interface definitions. Between methods. Between the local variables declarations in a method and its first statement. Before a block comment or single-line comment. Between logical sections inside a method to improve readability.

35. Blank Space Blank spaces should be used in the following circumstances. A keyword followed by a parenthesis should be separated by a space.

36. In argument lists, commas should be followed by a blank space. Any comment delimiter and the actual comment should be separated by a blank space. Apart for the dot (.), all binary operators should have spaces between them and their operands. Unary operators like unary minus (-), increment (++), and decrement (--) should never be separated from their operands by blank spaces

37. The expressions in a for statement should be separated by blank spaces.

38. 09 Naming Convention

39. Programs are easier to understand by making them easier to read through the use of naming conventions. Packages Names The prefix of a unique package name is usually expressed in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu , gov , mil, net, org, or one of the English two-letter codes identifying nations as specified in ISO Standard 3166, 1981. The package prefix used in this instance is org.banana .

40. Method Names Methods should be verbs with the first letter capitalized and in mixed case, with the first letter of each internal word lowercase. Method names ought to be clear and informative.

41. Variable Names Variable names ought to be brief but descriptive. Temporary variables are frequently referred to as I j, k, m, and n for integers and c, d, and e for characters.

42. Constant Names The names of variables declared class constants (static final) and of ANSI constants should be all uppercase with words separated by underscores (_).

43. 10 Programming Practices

44. Avoid using an object to access a class (static) variable or method. Use a class name instead. For example: Referring to Class Variables and Methods

45. Numerical constants (literals) should not be coded directly, except for -1, 0, and 1, which can appear in a for loop as counter values. Constants Variable Assignments Do not assign several variables to the same value in a single statement. It is hard to read.

46. Miscellaneous Practices Parentheses Parentheses should be used frequently in expressions with mixed operators to prevent operator precedence issues.

47. Returning Values Avoid having several return statements in a method whenever you can. It is best programming practice to just have one method exit point; otherwise, debugging may be challenging.

48. If a binary operator-containing expression comes before the? in a ternary system? For clarity, the operator should be enclosed in parentheses. Expressions before `?' in the Conditional Operator

49. Special Comments To mark a comment as unusual or false but effective, use the symbol XXX . To mark anything as false and broken, use the FIXME flag.

50. Activity Prepare a piece of paper for our 15 pts activity

51. Activity Arrange the following Java Source Files in order: (3pts ) Class and interface declaration Header Comment Package and import statements 2. As a general principle, how many space should we use to indent? 3. How many declarations per line is recommended? 4. In special comments, to mark a comment as unusual or false but effective, what symbol should we use? 5. In special comments, to mark anything as false and broken, what flag should we use? I. Identification

52. II. Match the following pictures by its corresponding answer. ( Direct answer ) Documentation Comments Temporarily Removing Code Trailing Comments Single-line Comments Block Comments 1 2 3 4 5 III . Are code conventions important? Why? (Own answer) (3pts)

53. T H A N K S FOR LISTENING