kaysen: переводы
Java Code Conventions / Соглашения по оформлению кода Java
→Comments should never include special characters such as form-feed and backspace.
0 Комментарии никогда не должны включать служебные символы, такие как возврат каретки и backspace.
→Comments should not be enclosed in large boxes drawn with asterisks or other characters.
0 Комментарии не должны быть вложены в большие блоки, со звездочками или другими символами.
→Note: The frequency of comments sometimes reflects poor quality of code. When you feel compelled to add a comment, consider rewriting the code to make it clearer.
0 Замечание: Частота комментариев иногда отражает низкое качество кода. Если Вы почувствуете, что нужно добавить ещё комментариев, подумайте, вероятно нужно переписать такой код, что бы сделать его более понятным.
→Discussion of nontrivial or nonobvious design decisions is appropriate, but avoid duplicating information that is present in (and clear from) the code. It is too easy for redundant comments to get out of date. In general, avoid any comments that are likely to get out of date as the code evolves.
0 Пояснение нетривиальных или неочевидных проектных решений допускается, но следует избегать дублирование информации, которая присутствует в коде (и понятна из него). Избыточные комментарии быстро устаревают. Вообще, избегайте любых комментариев, которые, скорее всего, устареют при развитии кода.
→Comments should be used to give overviews of code and provide additional information that is not readily available in the code itself. Comments should contain only information that is relevant to reading and understanding the program. For example, information about how the corresponding package is built or in what directory it resides should not be included as a comment.
0 Комментарии должны использоваться, чтобы дать краткий обзор кода и предоставить дополнительную информацию, которую нельзя легко получить из кода непосредственно. Комментарии должны содержать только информацию, которая относится к чтению и пониманию программы. Например, информация о том, как соответствующий пакет построен, или о том, в какой директории он находится, не должна быть включена как комментарий.
→Implementation comments are mean for commenting out code or for comments about the particular implementation. Doc comments are meant to describe the specification of the code, from an implementation-free perspective. to be read by developers who might not necessarily have the source code at hand.
0 Комментарии реализации - средства для того, чтобы прокомментировать код или особенности реализации. Комментарии документации предназначены для описания характеристик кода не зависящих от реализации, чтобы в будущем могли быть прочитанными разработчиком, у которого не обязательно будет под рукой исходный код.
→Java programs can have two kinds of comments: implementation comments and documentation comments. Implementation comments are those found in C++, which are delimited by /*...*/, and //. Documentation comments (known as "doc comments") are Java-only, and are delimited by /**...*/. Doc comments can be extracted to HTML files using the javadoc tool.
0 У Java программ могут быть два вида комментариев: комментарии реализации и комментарии документации. Комментарии реализации, встречающиеся в C++, ограничиваются /*...*/ и //. Комментарии документации (известные как “doc comments”) встречаются только в Java, и ограничиваются / **...*/. Док комментарии, могут быть извлечены в HTML файлы при использовании javadoc tool.
→7 |Methods |These methods should be grouped by functionality rather than by scope or accessibility. For example, a private class method can be in between two public instance methods. The goal is to make reading and understanding the code easier.
0 7 | Методы | Эти методы должны группироваться больше по функциональности чем по области видимости или доступности. Например, private метод класса может быть между двумя случайными public методами. Цель – сделать чтение и понимание кода проще.
→6 |Constructors |
0 6 | Конструкторы
→5 |Instance variables |First public, then protected, and then private.
0 5 | Не статические переменные | Сначала public, затем protected, затем пакетные (без спецификатора доступа) и затем private.
→4 |Class (static) variables |First the public class variables, then the protected, and then the private.
0 4 | Статические переменные класса | Сначала public переменные класса, затем protected, затем пакетные (без спецификатора доступа) и затем private.
→3 |Class/interface implementation comment (/*...*/), if necessary |This comment should contain any class-wide or interface-wide information that wasn't appropriate for the class/interface documentation comment.
0 3 | Комментарии о реализации класса/интерфейса (/*...*/), если необходимо | Эти комментарии должны содержать расширенную информацию о классе/интерфейсе, которая не относится к комментариям документации класса/интерфейса
→2 |class or interface statement |
0 2 | Операторы class или interface
→1 |Class/interface documentation comment (/**...*/) |See "Documentation Comments" on page 9 for information on what should be in this comment.
0 1 | Комментарии к документации класса/интерфейса (/**...*/) | Смотрите “Комментарии к документации” на стр. 9 с информацией о том, что должно быть в этом комментарии.
→Java source files have the following ordering:
0 Исходные Java файлы имеют следующую структуру:
→Each Java source file contains a single public class or interface. When private classes and interfaces are associated with a public class, you can put them in the same source file as the public class. The public class should be the first class or interface in the file.
1 Каждый исходный Java файл содержит один public класс или интерфейс. Когда private классы и интерфейсы связанны с public классом, вы можете поместить их в тот же исходный файл что и public класс. Public класс должен быть первым классом или интерфейсом в файле.
→3.1 Java Source Files
0 3.1. Исходный Java файл
→A file consists of sections that should be separated by blank lines and an optional comment identifying each section.
1 Файл состоит из разделов, которые должны разделяться пустыми строками и необязательными комментариями, определяющими каждый раздел.
→README |The preferred name for the file that summarizes the contents of a particular directory.
0 README | Пердпочтительное имя для файла, который подводит итог содержимого определенного каталога.
→Frequently used file names include:
1 Часто используемые имена для файлов включают в себя:
Резюме
- Пол:
- мужчина
- Родной язык:
- русский
- С нами:
-
с 16 сентября 2011 г.
(5511 дней)
Не является членом клуба. - Деятельность:
-
30 версий перевода
с общим рейтингом 12
Карма: 1 (оценок: 1)