The blocks editor, such as the editor in Scratch, is widely applied for visual programming languages (VPL) nowadays. Despite it's friendly for non-programmers, it exists three main limitations while displaying block codes: (1) the readability, (2) the program structure, and (3) the re-use. To cope with these issues, we introduce a novel formatting tool, block shelves, into the editor for organizing blocks. A user could utilize shelves to constitute a user-defined structure for the VPL projects. Based on the experiment results, block shelves improves the block code navigating and searching significantly. Besides, for achieving code re-use, users could use shelf export import to share re-use their block codes between projects in the file format of eXtensible Markup Language (xml.) All functions were demonstrated on MIT App inventor 2, while all modifications were made in Google Blockly.
Approaches in improving the code readability and the code usability have been researched for decades, but the techniques designed and discussed are mostly for the text-based programs, such as indentation @cite_9 , coding style @cite_13 , variable naming @cite_5 , modulation @cite_11 , and applying text context to improve the productivity @cite_2 . However, more and more projects today are block-based. The current blocks editor design provides 3 functions: block commenting, block collapsing and sorting by block category, and block duplicating to manage the readability issues, the structure, and the re-use of block codes. The details of the functions are explained in the following.
@cite_9 @cite_2 @cite_5 @cite_13 @cite_11
2030432320 2130344546 2091280632 1969685458 2151191515
When working on a large software system, a programmer typically spends an inordinate amount of time sifting through thousands of artifacts to find just the subset of information needed to complete an assigned task. All too often, before completing the task the programmer must switch to working on a different task. These task switches waste time as the programmer must repeatedly find and identify the information relevant to the task-at-hand. In this paper, we present a mechanism that captures, models, and persists the elements and relations relevant to a task. We show how our task context model reduces information overload and focuses a programmer's work by filtering and ranking the information presented by the development environment. A task context is created by monitoring a programmer's activity and extracting the structural relationships of program artifacts. Operations on task contexts integrate with development environment features, such as structure display, search, and change management. We have validated our approach with a longitudinal field study of Mylar, our implementation of task context for the Eclipse development environment. We report a statistically significant improvement in the productivity of 16 industry programmers who voluntarily used Mylar for their daily work. The question of whether the use of good naming style in programs improves program comprehension has important implications for both programming practice and theories of program comprehension. Two experiments were done based on Pennington's (Stimulus structures and mental representations in expert comprehension of computer programs, Cognitive Psychology,19, 295-341, 1987) model of programmer comprehension. According to her model, different levels of knowledge, ranging from operational to functional, are extracted during comprehension in a bottom-up fashion. It was hypothesized that poor naming style would affect comprehension of function, but would not affect the other sorts of knowledge. An expertise effect was found, as well as evidence that knowledge of program function is independent of other sorts of knowledge. However, neither novices nor experts exhibited strong evidence of bottom-up comprehension. The results are discussed in terms of emerging theories of program comprehension which include knowledge representation, comprehension strategies, and the effects of ecological factors such as task demands and the role-expressiveness of the language. The consensus in the programming community is that indentation aids program comprehension, although many studies do not back this up. We tested program comprehension on a Pascal program. Two styles of indentation were used--blocked and nonblocked--in addition to four passible levels of indentation (0, 2, 4, 6 spaces). Both experienced and novice subjects were used. Although the blocking style made no difference, the level of identation had a significant effect on program comprehension. (2--4 spaces had the highest mean score for program comprehension.) We recommend that a moderate level of indentation be used to increase program comprehension and user satisfaction. A central feature of the evolution of large software systems is that change-which is necessary to add new functionality, accommodate new hardware, and repair faults-becomes increasingly difficult over time. We approach this phenomenon, which we term code decay, scientifically and statistically. We define code decay and propose a number of measurements (code decay indices) on software and on the organizations that produce it, that serve as symptoms, risk factors, and predictors of decay. Using an unusually rich data set (the fifteen-plus year change history of the millions of lines of software for a telephone switching system), we find mixed, but on the whole persuasive, statistical evidence of code decay, which is corroborated by developers of the code. Suggestive indications that perfective maintenance can retard code decay are also discussed.