From 29d82affa058240dcf3f68b7f68a9d2a4560bec5 Mon Sep 17 00:00:00 2001 From: "Andy J. Ko" Date: Tue, 23 Apr 2019 20:20:42 -0700 Subject: [PATCH] Fixed #21, reducing claims about notation impact. --- comprehension.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/comprehension.html b/comprehension.html index 1e3eed4..7cb4647 100644 --- a/comprehension.html +++ b/comprehension.html @@ -123,12 +123,13 @@

- These differences in notation have real impact. + These differences in notation can have some impact. Encapsulation through data structures leads to better comprehension that monolithic or purely functional languages (Woodfield et al. 1981, Bhattacharya & Neamtiu 2011). Declarative programming paradigms (like CSS or HTML) have greater comprehensibility than imperative languages (Salvaneschi et al. 2014). - In general, statically typed languages like Java (which require developers to declare the data type of all variables) result in fewer defects (Ray et la. 2014), better comprehensibility because of the ability to construct better documentation (Endrikat et al. 2014), and result in easier debugging (Hanenberg et al. 2013). + Statically typed languages like Java (which require developers to declare the data type of all variables) result in fewer defects (Ray et la. 2014), better comprehensibility because of the ability to construct better documentation (Endrikat et al. 2014), and result in easier debugging (Hanenberg et al. 2013). In fact, studies of more dynamic languages like JavaScript and Smalltalk (Callaú et al. 2013) show that the dynamic features of these languages aren't really used all that much anyway. - All of this evidence suggests that that the more you tell a compiler about what your code means (by declaring types, writing functional specifications, etc.), the more it helps the other developers know what it means too. + Despite all of these measurable differences, the impact of notation seems to be modest in practice (Ray et al. 2014). + All of this evidence suggests that that the more you tell a compiler about what your code means (by declaring types, writing functional specifications, etc.), the more it helps the other developers know what it means too, but that this doesn't translate into huge differences in defects.

Code editors, development environments, and program comprehension tools can also be helpful. Early evidence showed that simple features like syntax highlighting and careful typographic choices can improve the speed of program comprehension (Baecker 1988). I have also worked on several tools to support program comprehension, including the Whyline, which automates many of the more challenging aspects of navigating dependencies in code, and visualizes them (Ko & Myers 2009):