Group: programming notation
Topic: comments
Topic: debugging by reading code
Topic: design pattern
Topic: goto statement
Topic: indentation
Topic: literate programming
Topic: naming conventions
Topic: program listing
Topic: programming with natural language
Topic: sections of a program
Topic: software documentation
Topic: software review
Topic: understanding systems
| |
Subtopic: programming as dialogue
Quote: want a dialogue style of programming with a modular distribution of knowledge and clean communication between pieces of knowledge [»atkiR_1977]
| Subtopic: refactoring
Ref: Fowler, Martin et al, Refactoring: improving the design of existing code, Addison Wesley 1999.
Subtopic: understandability
Quote: a book on how to write good, understandable programs that are correct the first time [»ledgHF_1975]
| Quote: style is the consistent pattern of choices; good coding style is easily understood, straightforward, and elegant [»fairRE_1985]
| Quote: programming style is measured by the effort needed to understand code [»gordRD3_1979]
| Quote: what can be said at all, can be said clearly [»dijkEW_1979]
| Quote: a program is readable if novices can understand it in terms of its subject area [»spooCR4_1986]
| Quote: if it is hard to understand something, it is hard to find inspirations and to avoid mistakes [»greeTR_1980]
| Quote: a measure of program understanding is the number of times spent viewing the program in order to answer a question [»scanDA9_1989]
| Subtopic: readability
Quote: programming languages should emphasize readability by human beings, not computers [»hoarCA_1974]
| Quote: the readability of programs is immeasurably more important than their writeability; self-documenting code; pleasant style [»hoarCA_1974]
| Quote: in exploratory development environments, program readability is critical
| Quote: an easy to read program is easier to write since programmers must check their work
| Quote: unary Smalltalk messages can be composed into readable expressions [»xlrg8_1981]
| Subtopic: self-documentation
Quote: a true test of self-documenting design is whether its maintainability is maintained [»weinGM_1982]
| Quote: a program's results are convincing only if the program is clear and its structure reflects the task [»dijkEW5_1965]
| Subtopic: determinism
Quote: threaded programs rely on programming style to constrain their nondeterminism
| Subtopic: specifications
Quote: need specification standards with pragmatics, formating, naming conventions, language restrictions [»tretJ9_2001]
| Subtopic: guidelines
Quote: coding rules for safety-critical applications in C; e.g., simple control flow, short functions, assertions, check args, avoid pointers, no warnings [»holzGJ6_2006]
| Quote: programming guidelines require motivation, participation, revision, exceptions, and automated adherence [»fairRE_1985]
| QuoteRef: ledgHF7_1977 ;;102 standard heading: title, name, summary, descriptions of input and output files, notes
| QuoteRef: cwalK_2006 ;;Framework Design Guidelines: Conventions, Idioms, and patterns for reusable .NET libraries
| Quote: the most readable program was procedureless with comments, the least was procedureless without comments (73 lines of code) [»tennT9_1988]
| Quote: programming languages should not favour abbreviation of writing by default conventions and implicit assumptions
| Quote: all programming styles indent the body of structured constructs [»leavGT2_1984]
| Quote: specifying data types makes code more readable [»nielJ5_1989]
| Quote: avoid unnecessary spaces [»cwalK_2006]
| Quote: order class members by field, constructors, properties, methods, events, implementation, private members, and nested types [»cwalK_2006]
| Subtopic: context
Quote: need conventions to reduce uncertainty about a machine's state; computers have very great flexibility [»turiA3_1951]
| Quote: in object-oriented programming, more than one variable may be polymorphic; requires case analysis and poor modularity [»ingaDH9_1986]
| Subtopic: stylized representation
Quote: use a stylized representation for design concepts that do not match the programming language; e.g., delegation in C++ [»stroB_1991]
| Subtopic: literate programming
Quote: literate programs written for understanding by humans; programmer as essayist; concepts presented in best order either formally or informally [»knutDE2_1984]
| Subtopic: program review
Quote: need a rigorous review after programming and before debugging; often caused major improvements or revised design strategies [»corbFJ_1979]
| Subtopic: style checker
Quote: C's lint program caches most type errors; misses union types and use of explicit escapes [»ritcDM7_1978c]
| Quote: a bug checker uses static analysis to find correctness violations; while a style checker identifies code style violations [»hoveD12_2004]
| Subtopic: efficiency vs. readability
Quote: military programmers are so concerned about efficiency that they will tune for their compiler even though readability is destroyed [»goodJB8_1976]
| Subtopic: language for readable programs
Quote: PDS is a programming environment that does not enforce a programming discipline; but hopefully it encourages good programming practices [»cheaTE_1979]
| Quote: a programming language should maximize the ability to write readable programs [»spooCR4_1986]
| Quote: a programming language's style should reduce housekeeping in its domain while allowing expression in other domains [»blumBI_1985]
| Quote: a programming language's style translates brief statements into complex functions
| Subtopic: small framework -- rich structure
Quote: a programming language should have a small framework that can accommodate many powerful features as changeable parts [»backJ8_1978a]
| Subtopic: parameters
Quote: use at most three parameters; do not use many parameters with the same type [»blocJ_2001]
| Quote: define parameters as interfaces instead of classes; greater flexibility without copy operations [»blocJ_2001]
| Subtopic: not p vs. else
Quote: in studies found 'if p..not p' far easier to understand than 'if..then..else'; later never used in natural languages [»greeTR_1980]
| Subtopic: mystery numbers
Quote: zero, one, and infinity are the only reasonable numbers in program language design [»maclBJ_1987]
| Quote: banned all mystery numbers above two [»clarBL9_1973]
| Quote: programmers used integer and character values as status values; indicated by comments [»goodJB2_1976]
| Subtopic: modifiable code
Quote: executable code should not be modified; was a big clarity problem with machine code [»dijkEW5_1965]
|
Related Topics
Group: programming notation (14 topics, 221 quotes)
Topic: comments (23 items)
Topic: debugging by reading code (11 items)
Topic: design pattern (17 items)
Topic: goto statement (25 items)
Topic: indentation (25 items)
Topic: literate programming (16 items)
Topic: naming conventions (8 items)
Topic: program listing (14 items)
Topic: programming with natural language (27 items)
Topic: sections of a program (9 items)
Topic: software documentation (64 items)
Topic: software review (80 items)
Topic: understanding systems (48 items)
|