Map
Index
Random
Help
Topics
th

Topic: programming style

topics > computer science > programming > Group: software engineering



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 up

Quote: want a dialogue style of programming with a modular distribution of knowledge and clean communication between pieces of knowledge [»atkiR_1977]

Subtopic: refactoring up

Ref: Fowler, Martin et al, Refactoring: improving the design of existing code, Addison Wesley 1999.

Subtopic: understandability up

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 up

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 up

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 up

Quote: threaded programs rely on programming style to constrain their nondeterminism

Subtopic: specifications up

Quote: need specification standards with pragmatics, formating, naming conventions, language restrictions [»tretJ9_2001]

Subtopic: guidelines up

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 up

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 up

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 up

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 up

Quote: need a rigorous review after programming and before debugging; often caused major improvements or revised design strategies [»corbFJ_1979]

Subtopic: style checker up

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 up

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 up

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 up

Quote: a programming language should have a small framework that can accommodate many powerful features as changeable parts [»backJ8_1978a]

Subtopic: parameters up

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 up

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 up

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 up

Quote: executable code should not be modified; was a big clarity problem with machine code
[»dijkEW5_1965]

Related Topics up

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)


Updated barberCB 11/04
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.