size of modules #16249
Replies: 5 comments
-
Well whatever you do, what a routine or module does, still has to be done, so I don't see how it helps. In fact passing back and forth between several small modules that might need to be called is probably more complex than having it in one if it is complex.
I have not really programmed in ages myself, but I tend to built often used functions into their own module or subroutine with variables that you eventually get to know the names of, their data types etc. It makes debugging easier if you know that the call is using a routine that works elsewhere.
Brian
…--
***@***.***
Sent via blueyonder.(Virgin media)
Please address personal E-mail to:-
***@***.***, putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: burmancomp
To: nvaccess/nvda
Cc: Subscribed
Sent: Saturday, March 02, 2024 8:39 AM
Subject: [nvaccess/nvda] size of modules (Discussion #16249)
I have not checked if there are other modules which are as large as braille module. Braille module has over 3000 lines, and it sounds big.
Maybe there are others in addition to me who are not advanced programmers. Smaller modules could help especially us to better learn and understand what how and why modules do.
I understand that this is also question of available resources. Refactoring code requires work, and this likely affects on implementing new features at least in short run. But would it help in long run?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Implementing new/developing existing features is easier when program design/structure is as easy as possible to learn/understand. Is current source code as easy to learn/understand as possible, and if not, what should/could be done. |
Beta Was this translation helpful? Give feedback.
-
Keeping code units small and focussed on a single task is definitely good practice and something like the Braille module (see issue #12772 ) being of that size would imply it may be dealing with a lot of different things. One complication in making such refactorings is what may be using the various functions, classes, etc. The problem being that NVDA doesn't actually restrict what addons may use, there is a lot of relying upon convention and such like as what should be used. It is possible to confirm NVDA code internally is updated for any changes, but it would be impossible to know that no addon uses a particular definition. Such a change would rely upon marking definitions as deprecated, ensuring needed changes are documented, giving time for addons to be updated and then finally a removal of the old definitions and then there may still be some breakage. Depending upon the restructuring it may or may not be so easy to follow such a process to reduce breakage. |
Beta Was this translation helpful? Give feedback.
-
+1 To what @mwhapples said. |
Beta Was this translation helpful? Give feedback.
-
Likely it will not be easier with time. What will result be if nothing is done? |
Beta Was this translation helpful? Give feedback.
-
I have not checked if there are other modules which are as large as braille module. Braille module has over 3000 lines, and it sounds big.
Maybe there are others in addition to me who are not advanced programmers. Smaller modules could help especially us to better learn and understand what how and why modules do.
I understand that this is also question of available resources. Refactoring code requires work, and this likely affects on implementing new features at least in short run. But would it help in long run?
Beta Was this translation helpful? Give feedback.
All reactions