Skip to content
Free planNo credit card requiredStart writing
AI for Research home
AI for Research home
Dashboard
Sign inGet started

Search 250 million research papers

Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.

About 7,568 papers for “Programming style”

C++ Programming Style

Tom Cargill · Medical Entomology and Zoology · 1992

Preface. Introduction. Bibliographic Notes. 1. Abstraction. Style Example: Pricing Computers. Finding a Common Abstraction. Differences Between Classes. Reintroducing Inheritance. Removing the Enumerations. Summary. Bibliographic Notes. Exercise. 2. Consistency. Style Example: Class string. Well-defined State. Consistent Physical State. Class Invariants. Consistent Use of Dynamic Memory. Deallocating Dynamic Memory. Style Example: A Second Approach. Summary. Bibliographic Notes. Exercises. 3. Unnecessary Inheritance. Style Example: Stacks. Inheritance Scope Rules. Inheritance Relationships. Encapsulation. Interface versus Implementation. Templates. Summary. Bibliographic Notes. Exercise. 4. Virtual Functions. Style Example: Vehicles and Garages. Consistency. Base Destructors. Inheritance. Coupling. Summary. Bibliographic Notes. Exercise. 5. Operator Overloading. Operator Overloading Basics. Style Example: Class FileArray. Inheritance for Implementation. A Programming Tradeoff: Overloaded Operators versus Member Functions. Summary. Bibliographic Notes. Exercises. 6. Wrappers. A C Library. Style Example: A C++ Wrapper for dirent. Multiple Directory Objects. Constructor Failure. Public Access to Failure State. Error Condition Argument. Summary. Bibliographic Notes. Exercise. 7. Efficiency. Style Example: Class BigInt. Exercising BigInt. The Length of Dynamic Strings. The Number of Dynamic Strings. The Client Code. Rewriting BigInt. Summary. Bibliographic Notes. Exercises. 8. A Case Study. Style Example: Finite State Machines. Initialization. Coupling. Cohesion. Modules versus Abstract Data Types. Generalization. Bibliographic Notes. Exercises. 9. Multiple Inheritance. Ambiguities under Multiple Inheritance. Directed Acyclic Inheritance Graphs. Exploring Virtual Base Classes. Style Example: Class Monitor. Style Example: A Virtual Base Class. Multiple Protocol Inheritance. Summary. Bibliographic Notes. Exercises. 10. Summary of Rules. Index. 0201563657T04062001

Cited by 18

Programming style: An example

Lester C. Welch · Computers in Physics · 1988

The relationship of programming style and ‘‘quality of software’’ is discussed. The quality of software is defined not only in objective terms, such as whether or not the answers are correct and the speed with which they are produced, but also in more subjective terms such as maintainability and readabilty. Examples in FORTRAN and C illustrate how stylistic features can improve software quality.

Cited by 1Open access

Extreme Programming: Maestro Style

Fox, Jason, Powell, Mark, Rabe, Kenneth et al. · NASA Technical Reports Server (NASA)

"Extreme Programming: Maestro Style" is the name of a computer programming methodology that has evolved as a custom version of a methodology, called extreme programming that has been practiced in the software industry since the late 1990s. The name of this version reflects its origin in the work of the Maestro team at NASA's Jet Propulsion Laboratory that develops software for Mars exploration missions. Extreme programming is oriented toward agile development of software resting on values of simplicity, communication, testing, and aggressiveness. Extreme programming involves use of methods of rapidly building and disseminating institutional knowledge among members of a computer-programming team to give all the members a shared view that matches the view of the customers for whom the software system is to be developed. Extreme programming includes frequent planning by programmers in collaboration with customers, continually examining and rewriting code in striving for the simplest workable software designs, a system metaphor (basically, an abstraction of the system that provides easy-to-remember software-naming conventions and insight into the architecture of the system), programmers working in pairs, adherence to a set of coding standards, collaboration of customers and programmers, frequent verbal communication, frequent releases of software in small increments of development, repeated testing of the developmental software by both programmers and customers, and continuous interaction between the team and the customers. The environment in which the Maestro team works requires the team to quickly adapt to changing needs of its customers. In addition, the team cannot afford to accept unnecessary development risk. Extreme programming enables the Maestro team to remain agile and provide high-quality software and service to its customers. However, several factors in the Maestro environment have made it necessary to modify some of the conventional extreme-programming practices. The single most influential of these factors is that continuous interaction between customers and programmers is not feasible.

Cited by 0Open access

Extreme Programming: Maestro Style

Jeffrey S. Norris, Jason Fox, Kenneth Rabe et al. · NASA Technical Reports Server (NASA) · 2009

Programming: Maestro Style is the name of a computer programming methodology that has evolved as a custom version of a methodology, called extreme programming that has been practiced in the software industry since the late 1990s. The name of this version reflects its origin in the work of the Maestro team at NASA's Jet Propulsion Laboratory that develops software for Mars exploration missions. Extreme programming is oriented toward agile development of software resting on values of simplicity, communication, testing, and aggressiveness. Extreme programming involves use of methods of rapidly building and disseminating institutional knowledge among members of a computer-programming team to give all the members a shared view that matches the view of the customers for whom the software system is to be developed. Extreme programming includes frequent planning by programmers in collaboration with customers, continually examining and rewriting code in striving for the simplest workable software designs, a system metaphor (basically, an abstraction of the system that provides easy-to-remember software-naming conventions and insight into the architecture of the system), programmers working in pairs, adherence to a set of coding standards, collaboration of customers and programmers, frequent verbal communication, frequent releases of software in small increments of development, repeated testing of the developmental software by both programmers and customers, and continuous interaction between the team and the customers. The environment in which the Maestro team works requires the team to quickly adapt to changing needs of its customers. In addition, the team cannot afford to accept unnecessary development risk. Extreme programming enables the Maestro team to remain agile and provide high-quality software and service to its customers. However, several factors in the Maestro environment have made it necessary to modify some of the conventional extreme-programming practices. The single most influential of these factors is that continuous interaction between customers and programmers is not feasible.

Cited by 0

Programming style authorship analysis

Paul Oman, C. Cook · 1989

Detecting instances of software theft and plagiarism is a difficult problem. The statistical analysis of peculiar words or phrases known to be used by an author is a common method of settling authorship disputes in English literature. This paper presents a similar method for identifying authorship of programs. The method is based on typographic or layout style program characteristics. Our experiments show that these characteristics can be useful in determining authorship. The major benefits of the method are that it is simple, easy to automate, and can be used in conjunction with other program fingerprinting methodologies.

Cited by 53

Functional-Style Programming, continued

Will Briggs · Apress eBooks · 2025

Functional-style programming – passing functions as arguments to other functions, pipelines, lazy evaluation – is all the rage in C++ right now.

Cited by 0

ONTOLOGY-DRIVEN PROGRAMMING STYLE ASSISTANT

Ніка Миколаївна; Національний авіаційний університет Сидорова · Problems of a systemic approach to the economy enterprises (National Aviation University, Ukraine, Kyiv) · 2017

Cited by 0Open access

Programming in style with bach

Andrea Agostini, Daniele Ghisi, Jean‐Louis Giavitto · HAL (Le Centre pour la Communication Scientifique Directe) · 2019

ISBN 979-10-97-498-01-6. A post-proceeding version is planed at LNCS Springer. The proceedings are available at URL: https://cmmr2019.prism.cnrs.fr/Docs/Proceedings_CMMR2019.pdf

Cited by 0Open access

Program complexity and programming style

Michael Evangelist · 1984

In a recent paper <sup xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">(1)</sup> the author has presented evidence that, contrary to several studies in the literature, certain software complexity metrics are not consistently sensitive to the application of program style rules. In the present paper, these results are summarized and extended to two additional metrics. The new results indicate both that current complexity metrics are improper indices of program quality, as measured by style, and that many commonly used style rules do not address questions of minimizing interprocedural information flow complexity.

Cited by 8

Programming Style: Examples and Counterexamples

Brian W. Kernighan, P. J. Plauger · ACM Computing Surveys · 1974

Computer programs can be written many different ways and still achieve the same effect Until recently, programmers have had little reason to favor one method of expressing code over another. We have come to learn, however, that functionally equivalent programs can have extremely important stylistic differences.

Cited by 34Open access

The Elements of Programming Style

Charles B. Kreitzberg, Ben Shneiderman · The Journal of Data Education · 1973

(1973). The Elements of Programming Style. The Journal of Data Education: Vol. 13, New Orleans Convention April 17th to 20th, 1973, pp. 28-29.

Cited by 166

Programming Style Guidelines for Java

Debajyoti Bandyopadhyay, K. Kishore, R. Balamurugan · Institutional Repository @ NAL (University of Southampton) · 2004

Effective programming style, as we know, helps us write code that is easier to understand,13; debug, maintain, and port from one system to another.13;

Cited by 0

Knowing and Programming with Style

Jordan, Debra J., York, Sherril L. · UNI ScholarWorks (University of Northern Iowa) · 1995

In a world where youth programs compete for participants administrators and programmers constantly strive for new and creative programming ideas as well as new ways of offering traditional programs. The state of the art in youth programming demands that youth service workers be in tune with the people who are being served, and not merely the programs which are being provided. This includes understanding differences - cultural, regional, personal, etc. Program administrators and leaders need to recognize that everyone has differences which are neither good nor bad - they are simply different. Too often value and worth are attributed to differences thus negatively impacting those with lesser attributed value. It is also important that youth workers consciously acknowledge that each participant is special and unique in their own right. In recognizing these unique qualities, it is helpful if program leaders understand personal styles and preferences which are manifested through attitudes and behaviors. A framework for understanding personal behavioral styles is presented in this paper. The framework is based on a model that characterizes behaviors by placing them along two axes related to speed of pace and task/people orientation. Once the model has been presented, implications for programming and program leadership will be discus ed.

Cited by 0

Broadcasting in CSP-Style Programming

Brian Vinter, Kenneth Skovhede, Mads Ohm Larsen · IOS Press eBooks · 2018

While CSP-only models process-to-process rendezvous-style message passing, all newer CSP-type programming libraries offer more powerful mechanisms, such as buffered channels, and multiple receivers, and even multiple senders, on a single channel. This work investigates the possible variations of a one-to-all, broadcasting, channel. We discuss the different semantic meanings of broadcasting and show three different possible solutions for adding broadcasting to CSP-style programming.

Cited by 0Open access

Programming without data: Towards a totally functional programming style

Paul A. Bailes · 2001

The identity of programming with language extension has interesting consequences. If language extension implies programming, then language extension should be constrained by the requirements of what can be expected of a programmer, in particular the avoidance of the need to write interpreters, which can be satisfied by an (augmented) functional basis. If programming implies language extension, then programming should explicitly be conducted so, in particular avoiding illegitimate extension techniques, specifically the interpretation of inert data. Comprehensive replacement of data by functions shows potential for achieving this outcome. While numerous technical objectives remain to be met, the implications of the effort have wide ramifications, not just for software development.

Cited by 1