5 ms·

I expected some science, however it's just subjective rules backed by nothing substantial.

klibertp 10y ago
That's because no one even knows how to start doing "science" in this direction. When you read the code there are so many different things influencing your understanding that it's hard to impossible to even list them all. And if you take a look at some of the things that might influence your understanding you'll notice that most of them are very hard to impossible to measure. From the top of my head, things which may have an impact: * your level of skill in a given language * your level of familiarity with the style of a particular programmer who wrote the code * the tools you have at your disposal (go to definition, see docs functions of IDEs) * your familiarity with a particular framework used * your preference and expectations regarding the identifiers * your knowledge of what the system as a whole (or its part) is supposed to do * your familiarity with the project structure And so on, and that's even before we start talking about concrete examples of readable code and trying to get some metrics on it! Writing code is no more susceptible to scientific analysis than writing prose when it comes to other people reading the code (and not machines executing it). To write good code you need to first assume something about your readers (their level of skill, prior experiences, etc.) and then optimize the form of the code so that it doesn't confuse them (too short) or bore them (too long). Seriously, writing prose and code (the latter only if meant for human consumption) is very similar: you need structure, things following one another, sentences of appropriate length and "density" and so on in both kinds of writing. Programmers could learn a lot from writers, but they most often refuse to do so. Literate Programming should be the default by now, yet is still used very rarely...
- mybrid 10y ago
  "That's because no one even knows how to start doing "science" in this direction." No true, there is an entire field of usability science. It is all still limited to experimental learnings as opposed to theoretical deterministic knowns. Currently usability testing is only be applied to end users. There is no reason task analysis and the Jakob Neilson's 10 heuristic rules of basic usability cannot be applied to software itself. I apply the science of usability to written software.
  - mikulas_florek 10y ago
    Yes, but how many "usability studies" are done for writing software? I've seen onle a few and people write articles like this without any proofs daily.
- mikulas_florek 10y ago
  Science is hard, especially if done properly. The least they could do is to spit teams in two groups, based on whether they use a technique or not (e.g. unit testing, using OOP) and see if it makes any difference. It's far from perfect, but better than nothing. > That's because no one even knows how to start doing "science" in this direction. I suspect the reason almost no one do SW science is that nobody really cares. Most people just repeat some dogmas they like, e.g. they say: "you broke liskov substitution principle, that's bad" without any proof. I guess people just like flamewars (who doesn't :)
  - cessor 10y ago
    As my other comments outline, there is some science, although you are right in that empirical work on software engineering is a very small niche. Most people just report studies like: "Hey, look what I cooked up in my basement using haskell". - which to me, is engineering, not science.
- cessor 10y ago
  > That's because no one even knows how to start doing "science" in this direction I am sorry to disagree, but this is just not true. http://www.ptidej.net/courses/inf6306/fall10/slides/course8/Storey06-TheoriesMethodsToolsProgramComprehension.pdf http://www.ptidej.net/courses/inf6306/fall10/slides/course8/... http://www.cs.kent.edu/~jmaletic/papers/EMSE12.pdf http://www.cs.kent.edu/~jmaletic/papers/EMSE12.pdf https://link.springer.com/journal/10664 https://link.springer.com/journal/10664 https://scholar.google.com/citations?view_op=view_citation&hl=de&user=2WeXBokAAAAJ&citation_for_view=2WeXBokAAAAJ:k_IJM867U9cC https://scholar.google.com/citations?view_op=view_citation&h... I have to say this: https://brains-on-code.github.io/shorter-identifier-names.pdf https://brains-on-code.github.io/shorter-identifier-names.pd... My supervisor has to say this: http://pi.informatik.uni-siegen.de/stt/34_2/01_Fachgruppenberichte/WSRDFF/wsre_dff_2014-18_submission_w10.pdf http://pi.informatik.uni-siegen.de/stt/34_2/01_Fachgruppenbe... These are just the ones from the top of my head that I can google quickly, if you want I would be happy to share my zotero database or a large bibtex file. > When you read the code there are so many different things influencing your understanding that it's hard to impossible to even list them all. You are completely right: Psychological research on programming shows that it is a very complex cognitive task, best done by experts, and poorly understood. You describe knowledge and experience, and they in fact matter a lot. The above studies, for example, show (often just as a sideeffect), that experts are impacted less severely by badly written code (however that was operationalized). > Literate Programming should be the default by now I agree.
  - klibertp 10y ago
    There's nothing to be sorry about, actually, I'm really happy to learn that such research is being done! I tried searching for similar studies quite a few years back and came back empty-handed, so I assumed it's either not done at all or is very niche. As you seem to be knowledgeable about the field, how relevant/applicable you think the studies you linked to are in the general case? In the study about identifier length, for example, seems to be very specific and I'm not convinced at all the results would be the same in a different language, with different people and even with slightly different identifiers (abbreviating start to str vs. beginning to beg, for example). EDIT: another thought on the study: does it control for presence or absence of widely known conventions? For example in Haskell, OCaml and others it's customary to write `x :: xs` - would writing `element :: list` instead improve the time needed to comprehend the code? On the other hand, in Smalltalk, you frequently write `add: aNumber to: aList` - the identifiers are longer, but they provide additional (type) information which is otherwise not present. So how long the identifiers need to be may depend heavily on the language (the study used C# I think), is it accounted for in the paper? Still, all the papers you mentioned look interesting and I will read them once I have some time. Thanks for posting! :)

That's because no one even knows how to start doing "science" in this direction. When you read the code there are so many different things influencing your understanding that it's hard to impossible to even list them all. And if you take a look at some of the things that might influence your understanding you'll notice that most of them are very hard to impossible to measure. From the top of my head, things which may have an impact: * your level of skill in a given language * your level of familiarity with the style of a particular programmer who wrote the code * the tools you have at your disposal (go to definition, see docs functions of IDEs) * your familiarity with a particular framework used * your preference and expectations regarding the identifiers * your knowledge of what the system as a whole (or its part) is supposed to do * your familiarity with the project structure And so on, and that's even before we start talking about concrete examples of readable code and trying to get some metrics on it! Writing code is no more susceptible to scientific analysis than writing prose when it comes to other people reading the code (and not machines executing it). To write good code you need to first assume something about your readers (their level of skill, prior experiences, etc.) and then optimize the form of the code so that it doesn't confuse them (too short) or bore them (too long). Seriously, writing prose and code (the latter only if meant for human consumption) is very similar: you need structure, things following one another, sentences of appropriate length and "density" and so on in both kinds of writing. Programmers could learn a lot from writers, but they most often refuse to do so. Literate Programming should be the default by now, yet is still used very rarely...

mybrid 10y ago
"That's because no one even knows how to start doing "science" in this direction." No true, there is an entire field of usability science. It is all still limited to experimental learnings as opposed to theoretical deterministic knowns. Currently usability testing is only be applied to end users. There is no reason task analysis and the Jakob Neilson's 10 heuristic rules of basic usability cannot be applied to software itself. I apply the science of usability to written software.
- mikulas_florek 10y ago
  Yes, but how many "usability studies" are done for writing software? I've seen onle a few and people write articles like this without any proofs daily.
mikulas_florek 10y ago
Science is hard, especially if done properly. The least they could do is to spit teams in two groups, based on whether they use a technique or not (e.g. unit testing, using OOP) and see if it makes any difference. It's far from perfect, but better than nothing. > That's because no one even knows how to start doing "science" in this direction. I suspect the reason almost no one do SW science is that nobody really cares. Most people just repeat some dogmas they like, e.g. they say: "you broke liskov substitution principle, that's bad" without any proof. I guess people just like flamewars (who doesn't :)
- cessor 10y ago
  As my other comments outline, there is some science, although you are right in that empirical work on software engineering is a very small niche. Most people just report studies like: "Hey, look what I cooked up in my basement using haskell". - which to me, is engineering, not science.
cessor 10y ago
> That's because no one even knows how to start doing "science" in this direction I am sorry to disagree, but this is just not true. http://www.ptidej.net/courses/inf6306/fall10/slides/course8/Storey06-TheoriesMethodsToolsProgramComprehension.pdf http://www.ptidej.net/courses/inf6306/fall10/slides/course8/... http://www.cs.kent.edu/~jmaletic/papers/EMSE12.pdf http://www.cs.kent.edu/~jmaletic/papers/EMSE12.pdf https://link.springer.com/journal/10664 https://link.springer.com/journal/10664 https://scholar.google.com/citations?view_op=view_citation&hl=de&user=2WeXBokAAAAJ&citation_for_view=2WeXBokAAAAJ:k_IJM867U9cC https://scholar.google.com/citations?view_op=view_citation&h... I have to say this: https://brains-on-code.github.io/shorter-identifier-names.pdf https://brains-on-code.github.io/shorter-identifier-names.pd... My supervisor has to say this: http://pi.informatik.uni-siegen.de/stt/34_2/01_Fachgruppenberichte/WSRDFF/wsre_dff_2014-18_submission_w10.pdf http://pi.informatik.uni-siegen.de/stt/34_2/01_Fachgruppenbe... These are just the ones from the top of my head that I can google quickly, if you want I would be happy to share my zotero database or a large bibtex file. > When you read the code there are so many different things influencing your understanding that it's hard to impossible to even list them all. You are completely right: Psychological research on programming shows that it is a very complex cognitive task, best done by experts, and poorly understood. You describe knowledge and experience, and they in fact matter a lot. The above studies, for example, show (often just as a sideeffect), that experts are impacted less severely by badly written code (however that was operationalized). > Literate Programming should be the default by now I agree.
- klibertp 10y ago
  There's nothing to be sorry about, actually, I'm really happy to learn that such research is being done! I tried searching for similar studies quite a few years back and came back empty-handed, so I assumed it's either not done at all or is very niche. As you seem to be knowledgeable about the field, how relevant/applicable you think the studies you linked to are in the general case? In the study about identifier length, for example, seems to be very specific and I'm not convinced at all the results would be the same in a different language, with different people and even with slightly different identifiers (abbreviating start to str vs. beginning to beg, for example). EDIT: another thought on the study: does it control for presence or absence of widely known conventions? For example in Haskell, OCaml and others it's customary to write `x :: xs` - would writing `element :: list` instead improve the time needed to comprehend the code? On the other hand, in Smalltalk, you frequently write `add: aNumber to: aList` - the identifiers are longer, but they provide additional (type) information which is otherwise not present. So how long the identifiers need to be may depend heavily on the language (the study used C# I think), is it accounted for in the paper? Still, all the papers you mentioned look interesting and I will read them once I have some time. Thanks for posting! :)