maintainability

Speed Comparisons - Procedural vs. OO in interpreted languages

人盡茶涼 提交于 2019-12-04 23:59:45
In interpreted programming languages, such as PHP and JavaScript, what are the repercussions of going with an Object Oriented approach over a Procedural approach? Specifically what I am looking for is a checklist of things to consider when creating a web application and choosing between Procedural and Object Oriented approaches, to optimize not only for speed, but maintainability as well. Cited research and test cases would be helpful as well if you know of any articles exploring this further. Bottom line: how big (if any) is the performance hit really, when going with OO vs. Procedural in an

Mandatory use of braces

对着背影说爱祢 提交于 2019-12-04 17:12:22
问题 As part of a code standards document I wrote awhile back, I enforce "you must always use braces for loops and/or conditional code blocks, even (especially) if they're only one line." Example: // this is wrong if (foo) //bar else //baz while (stuff) //things // This is right. if (foo) { // bar } else { // baz } while (things) { // stuff } When you don't brace a single-line, and then someone comments it out, you're in trouble. If you don't brace a single-line, and the indentation doesn't

managing document.ready event(s) on a large-scale website

空扰寡人 提交于 2019-12-04 07:39:38
问题 NOTE: I have now created a jQuery plugin which is my attempt of a solution to this issue. I am sure that it could be improved and i've probably overlooked lots of use cases, so if anyone wants to give feedback feel free :-) https://github.com/WickyNilliams/ReadyBinder I don't have a problem as such, but thought this would be an interesting point for discussion, and i hope people have some interesting ideas for this. Basically, i work on a large-scale website and increasingly we are writing

Mandatory use of braces

…衆ロ難τιáo~ 提交于 2019-12-03 10:10:28
As part of a code standards document I wrote awhile back, I enforce "you must always use braces for loops and/or conditional code blocks, even (especially) if they're only one line." Example: // this is wrong if (foo) //bar else //baz while (stuff) //things // This is right. if (foo) { // bar } else { // baz } while (things) { // stuff } When you don't brace a single-line, and then someone comments it out, you're in trouble. If you don't brace a single-line, and the indentation doesn't display the same on someone else's machine... you're in trouble. So, question: are there good reasons why

How to self-document a callback function that is called by template library class?

本小妞迷上赌 提交于 2019-12-03 09:55:16
I have a function User::func() (callback) that would be called by a template class ( Library<T> ). In the first iteration of development, everyone know that func() serves only for that single purpose. A few months later, most members forget what func() is for. After some heavy refactoring, the func() is sometimes deleted by some coders. At first, I didn't think this is a problem at all. However, after I re-encountered this pattern several times, I think I need some counter-measure. Question How to document it elegantly? (cute && concise && no additional CPU cost) Example Here is a simplified

'from X import a' versus 'import X; X.a'

三世轮回 提交于 2019-12-03 09:40:44
问题 I've seen some Python programmers use the following style fairly consistently (we'll call it style 1): import some_module # Use some_module.some_identifier in various places. For support of this style, you can cite the "explicit is better than implicit" maxim. I've seen other programmers use this style (style 2): from some_module import some_identifier # Use some_identifier in various places. The primary benefit that I see in style 2 is maintainability -- especially with duck typing ideals I

small code redundancy within while-loops (doesn't feel clean)

你离开我真会死。 提交于 2019-12-03 07:30:34
问题 So, in Python (though I think it can be applied to many languages), I find myself with something like this quite often: the_input = raw_input("what to print?\n") while the_input != "quit": print the_input the_input = raw_input("what to print?\n") Maybe I'm being too picky, but I don't like how the line the_input = raw_input("what to print?\n") has to get repeated. It decreases maintainability and organization. But I don't see any workarounds for avoiding the duplicate code without further

Cruft code. IoC to the rescue

无人久伴 提交于 2019-12-03 03:45:31
问题 In question about usefulness of IoC Container, the winning submitter mentioned that with an IoC container you can take this: public class UglyCustomer : INotifyPropertyChanged { private string _firstName; public string FirstName { get { return _firstName; } set { string oldValue = _firstName; _firstName = value; if(oldValue != value) OnPropertyChanged("FirstName"); } } private string _lastName; public string LastName { get { return _lastName; } set { string oldValue = value; _lastName = value

Design of an Alternative (Fluent?) Interface for Regular Expressions

主宰稳场 提交于 2019-12-03 02:42:38
问题 I've just seen a huge regex for Java that made me think a little about maintainability of regular expressions in general. I believe that most people - except some badass perl mongers - would agree that regular expressions are hardly maintainable. I was thinking about how this situation could be fixed. So far, the most promising idea I have is using a fluent interface. To give an example, instead of: Pattern pattern = Pattern.compile("a*|b{2,5}"); one could write something like this import

'from X import a' versus 'import X; X.a'

╄→尐↘猪︶ㄣ 提交于 2019-12-03 01:13:40
I've seen some Python programmers use the following style fairly consistently (we'll call it style 1): import some_module # Use some_module.some_identifier in various places. For support of this style, you can cite the "explicit is better than implicit" maxim. I've seen other programmers use this style (style 2): from some_module import some_identifier # Use some_identifier in various places. The primary benefit that I see in style 2 is maintainability -- especially with duck typing ideals I may want to swap some_module for some_other_module. I also feel style 2 wins points with the