The readability of source code is essential for software maintenance. Since maintenance is an ongoing process, which is estimated to be 70 percent of the software development life cycle's total costs, it cannot be deprioritized. The readability of source code is likely to affect the program comprehension, which may help or create problems in the maintenance of the software. How different code features and functions affect the readability of source code have previously been investigated, and readability metrics have been developed. The project was initiated because of the lack of research on how programming knowledge and statically compared to dynamically typed programming languages affect the readability of the source code. A survey was conducted and included 21 computer science students with various programming knowledge, each rating eight code snippets, making it in total 168 ratings. The results showed that the type of programming language could improve the readability of source code. The results also showed that programming knowledge does not have a correlation with the ability to read source code.

Computer software is ubiquitous. More than 35 × 10 18 computer instructions are executed around the globe each second. As computers dominate more aspects of our lives, there is a growing need to reason more accurately about computer software. Most contemporary computer software is written using object-oriented (OO) programming languages, such as J AVA, C#, and C++. How should we mathematically characterize object-oriented software? This is the question this thesis addresses by presenting an accurate domain-theoretic model of mainstream object-oriented programming. Mainstream object-oriented languages are class-based. In such languages, the name of a class is part of the meaning of an object, a property often called "nominality". Most mainstream OO languages also conform to a static type discipline. Hence, the focus of this thesis is the construction of an accurate model of nominal, statically-typed OO languages. In statically-typed nominal OO languages, class names are also part of the meaning of corresponding class types, and class inheritance (subclassing) is explicitly declared; one class is a subclass of another only if it is declared as such. When static type systems are formulated to describe sets of objects, subtyping is defined so that subclassing is consistent with subtyping. Nevertheless, some programming languages (PL) theoreticians dismiss this identification as a design error because the only published models of OO languages exclude nominal information from objects and define subtyping in a way that ignores nominality. In nominal OO languages, program behavior depends on the nominal information embedded in objects. This thesis builds a model of OO languages called NOOP that includes nominal information and defines static types in accord with mainstream OO language designs. In NOOP , the meaning of every object includes its class name. Similarly, types are defined such that objects belong to a particular class type if and only if they are members of classes that inherit from the class corresponding to the class type. To demonstrate the utility of the model, we show that in NOOP inheritance and OO subtyping coincide. This work shows that mainstream OO languages are not technically defective in identifying inheritance and subtyping. In models that include nominal information and define types that respect nominal information, this identification is mathematically correct. The folklore among OO programming language researchers that "inheritance is not subtyping" is incorrect.

As predicted by Gordon Moore, the number of transistors on a chip has roughly doubled every two years. Microprocessors featuring over a billion transistors are no longer science fiction. For example, Intel’s Itanium 9000 series and Intel’s Xeon 7400 series of processors feature 1.7 and 1.9 billion transistors respectively. To keep up with the emerging needs of contemporary very large scale integration (VLSI) design, industrial hardware description languages (HDLs) like Verilog and VHDL must be significantly enhanced. This thesis pinpoints some of the main shortcomings of the latest Verilog standard (IEEE 1364-2005) and shows how to overcome them by extending the language in a backward compatible way. To be able to cope with more complex circuits, well-understood higher-level abstraction mechanisms are needed. Verilog is already equipped with promising generative constructs making it possible to concisely describe a family of circuits as a parameterized module; however these constructs suffer from two problems: First, their expressivity is limited and second, they are not adequately supported by current tools. For instance, there are no static guarantees about the properties of the description generated as a result of instantiating a generic description with particular parameter values. Addressing both problems while remaining backward compatible led us to select a statically typed two-level languages (STTL) formal framework. By formalizing a core subset of Verilog as an STTL, we were able to define a static type system capable of: 1) checking the realizability of a description, 2) detecting bus width mismatches and array bounds violations, and 3) providing parametric guarantees on the resources required to realize a generic description. The power of the chosen framework is once more demonstrated as it also allows us to enrich the language with a new set of constructs that are designed to be expanded away when instantiated. To experiment with these ideas we implemented VPP, a Verilog Preprocessor with a built-in type checker. VPP is an unobtrusive tool accepting extended Verilog descriptions but generating descriptions compatible with any tool compliant with the Verilog standard. Our experience throughout this research showed that STTLs present a particularly suitable framework to formalize and implement generative features of a language. / Rice University, National Science Foundation (NSF) SoD award 0439017, Intel Corporation, Semiconductor Research Corporation (SRC) Task ID 1403.001