Tag Info

New answers tagged

0

Chances are high that your helperfunctions all have their own special concern. Your outer function myFunction is just using these functions e.g. in a specific order or by passing the results between them. Therefore, injecting the helper functions into myFunction is a good approach: function firstStep() { console.log("I'm first."); } function ...


0

If I am making that type of refactoring, I generally do neither. Placing the functions outside of the refactored function can lead to a polluted namespace, placing the functions inside of the refactored function can mean the functions are re-created on each function call. // make function the return of a closure var myFunction = (function(){ // ...


2

The idea comes to mind that "array" length may change during the for loop execution, but we don't want to loop further than the original size, but I can't imagine such a scenario. The people talking about performance are probably correct that this is why it was written that way (the person who wrote it that way might not be correct that it ...


2

Maybe you could create a third project on your source control, which contains only the shared libraries. So in short, your other two projects will reference this shared group of source files. This would allow you to have a group of shared libraries which are self contained, and are not stored within the context of another project. This assumes that you ...


0

Have you considered to use branches? It sounds like you are not going to work on both projects at the same time. You can branch out the second project from the first one and if there is anything you'd like to move to your first project, then you can merge your changes.


2

The fetching of the length of the array can easily be "more expensive" then the actual action you iterate over. So if the set doesn't change, only query the length once. Not with arrays, but with record-sets coming from an sql server I've seen dramatic improvements by not querying the record-count every iteration. (of-course do this only if you can ...


17

The variable n ensures the generated code doesn't fetch the array length for every iteration. It's an optimization that might make a difference in run time depending on the language used, whether the array is actually a collection object or a JavaScript "array", and other optimization details.


3

I think the direct solution, especially to the sort of problem you exemplified, is to make mistakes conspicuous. If you look at the two lines you gave, the difference is actually quite subtle. You have to have a lot of detailed, nuanced syntax "in your mind" when reading it if you want to catch the mistake. You also have to keep an eye out for hard-to-see ...


1

Reflection is the primary method of creating convention-based systems. I would not be surprised to find it is in use heavily inside most MVC frameworks. It's a major component in ORMs. Chances are, you're already using components built with it every day. The alternative for such a use is configuration, which has its own set of drawbacks.


3

Use of reflection is often harmful in OO languages if not used with great awareness. I have lost count of how many bad questions I have seen on StackExchange sites where The language in use is OO The author wants to find out which type of object has been passed in and then call one of its methods The author refuses to accept that reflection is the wrong ...


2

I agree with all of the other answers, but the idea of defensive coding could also help here. When practicing defensive coding, we write our code under the assumption that it's going to be used incorrectly; whether by us, or someone else. In this case, your shell script has been used incorrectly (run 59 times instead of once). How could we defend against ...


1

As well as testing... I found that printing out the code on paper, then running the code in a debugger and ticker each line once I confirm that all the values were as expected in the debugger was a great way. This gets you to look at your code in another way. Driving the "debugger checking" with unit tests is nice...


3

Git should treat renaming a folder as files moved around the place (whether or not you use the git mv command). The other problem of changing the name of package is that users of the application won't get it as an update but as a new application. If it's a paid app, it can be annoying. If it's a free app, they may not notice the new version and your ...


6

Previous answers mentioned two points: Reviews. Testing. but there are also three additional elements which may help: Better visualization. By using tools which let you better visualize what you do, you may catch errors earlier. This is particularly illustrative with the cron jobs. Imagine you have a visualization tool which shows you, graphically, ...


12

You always have to be at least two steps away from disaster. That means you never directly push something you just wrote into production. You either test it, or you have it tested, or you have it reviewed, or figure out some other way to have a two step path to disaster. Sometimes I will leave something for the next day and review my work again before ...


45

Is there some kind of cultivatable behaviour [...] that can help me at least reduce such kind of mistake Absolutely, it is called four-eyes-principle. If you had you shown your crontab entry to a second person (a person knowing cron, of course), chances are high the mistake would have been avoided. In programming, when it comes to this, people mostly ...


15

You don't need ADHD to have this problem. It might be that you are working in environment where you get interrupted often or where you have to work on many things at the same time. So loosing track of your progress or making small mistakes is almost guaranteed. There is one thing you can do to reduce those errors : tests based on specification. First, you ...


4

Of course - it's not very effective to reinvent the wheel. If someone else has already solved the problem and made it freely available, why not take advantage of that? However, that road is full of pitfalls. If you don't truly understand what the code is doing and how, or it's a trusted and well known library, you don't want that in your production code. ...


1

It depends on the complexity of the binding operation. If it's just one line to populate the dropdown, encapsulating that in a method is unnecessary. If it's a dozen lines of database queries and looping over the result and whatever else, having a populateDropdownA method makes sense.


0

I think that is not good technique. Method should adhere single responsibility principle. Which means each method should have single responsibility. So it's better if you go with different method to bind each drop down. That's really help lot in future.


1

Yes, memorisation still has a place, just reduced compared to how it used to be. Pulling something out of your head is much faster than researching with Google. For example, lately I'm learning the Swift language and my first step was read a book with code examples and committing as much as possible to memory. I've read the book several times cover to ...


5

It's all about understanding. You don't really have to memorize code or something (besides syntax and control statements of course which come in handy sometimes) but you basically want to "memorize" concepts. For example "How can I save memory?" or "How can I parallelize my algorithm?" and/or "How to design a large software such that it is maintainable?" ...


4

Memorizing code for programming purposes makes about as much sense as memorizing Lord of the Rings if you want to write a fantasy novel.


1

It is more common to use source control branching in order to control what features are available within a particular version of the software. That said, applications that offer tiered functionality within the same version level will sometimes use the technique you describe. Usually, you'll see two main uses of the conditional definitions. The fist uses ...


3

@Mike and @X.L.Ant's answer already provide some excellent points. I can provide one other point that hasn't been mentioned yet. Ease of Editing & Tool Use - All kinds of things work better when you put your JS in a separate file. Here are some examples: JSHint/JSLint and other static code analysis tools Code beautification like JSBeautify Code ...


0

For me, the main difference in using one or more than one repository are the answers to the following questions: Are the multiple parts developed by the same team, have the same release cycle, the same customer? Then there are less reasons to split the one repository. Are the multiple parts highly dependent on each other? So splitting model, controller and ...


-1

I did a quick microbenchmark regarding this and I have provided full sources in github. My conclusion is that whether creating objects is expensive or not is not the issue, but continuously creating objects with the notion that the GC will take care of things for you will make your application trigger the GC process sooner. GC is a very expensive process ...


2

In switch statements, they're pretty much essential -- well, you can use extract method/class to break it down into one-line cases, but ... -- I don't think that's what your professor means. To break from a loop is considered by some to be a goto with another name. So is returning from the middle of a method. I have even seen a similar case used against ...


1

It depends on what language you're working with. Let's look at the informal definition of the Liskov Substitution Principle (herafter LSP): You should be able to use an instance of a subtype anywhere you could use the base type. That only tangentially impacts constructors. LSP doesn't particularly care how instances are created, only that once ...


7

There are two primary reasons: Separation of concerns - by having the code in a separate file it is separate from the HTML and may be changed without touching the HTML file. If used in multiple places it allows for a single place to make the change. DRY - Don't Repeat Yourself By having it in a separate file you don't have to repeat the code in several ...


11

First thing : A pure JS code in a separate file will be cached, reducing the amount of data transfered on each request. Unless you have a very small, page specific JS code, you shouldn't inline it. Other valid reasons are already pointed in Mike's answer. If you have to pass some values from the server to the JS, what you can do instead of injecting JSP ...


6

It's not exactly clear what you are asking. You can always prove a program correct, if you want. This is independent of the language. The question is, can you get the computer to do the proof for you, or at least check a proof given by you? And the answer is: Yes! In fact, the Curry-Howard-Isomorphism states that there is an isomorphism between logic and ...


2

Some thoughts: The proof doesn't know what you want to accomplish with your code. That's the domain of well-written software requirements. Tests (when used as a description of requirements, as in TDD) are proof of the software requirements, not the software itself. The proof can, and often does, exceed the complexity of the actual program. Proofs, ...


2

The test is whether you can take code written to interact with the base class, and without modification, get it to work with an instance of the derived class instead. That means in most circumstances, your example would violate LSP. However, in some circumstances it might not. If you're using a language like JavaScript that essentially ignores extra ...


0

Delivery Quality can be expressed as a function of cost and time. Future cost of software for maintenance and enhancements can only be expressed as function of current delivery quality. "Good enough is fine" --> I can live with the occasional crashes, maintenance cost, increased future feature adding cost..what I need NOW is a good enough ...


1

There are already several good answers. I would add that sometimes time to market is one of the requirements. For example, there are industries where a large fraction of sales are generated at trade shows; that means a hard deadline, and if you miss it, you've lost opportunity and probably market share. In such a case, it's typically necessary to have your ...


3

I think your reasoning is flawed because you consider "best practices" as boolean. However, it's not a question whether you apply them or not. It's "how much" you apply them. For example testing: you can do a couple of manual tests, cover the basic tests automatically, make an extensive automated suite, test also all your libraries/dependencies, ...


2

This really depends on the reaction of the customer when they get software they don't like. Very few will say, "Gee, you were right. We should have had tests." but most will feel like you should have been able to make those "simple" changes anyway. If you continue to struggle with customers, you need to stop asking them if they want you to create tests. ...


3

From what I have encountered, usually, to build what can be considered as good software, one needs to have a clear set of requirements, maybe not all of them, but at least a set of core rules which will not change. From this, you then choose your architecture, design patterns, languages and frameworks. The problem with this is that most of the times, the ...


4

I've never yet seen a customer who asked for poor-quality software. However, what they do want is the cheapest software, and they want it as soon as possible. The cheapest and quickest way to develop software is to throw something together as quickly as possible, then debug it until it does pretty much what you wanted, and doesn't crash too often. At that ...


4

You could always use an interface or an abstract class to define the contract where you have generalized behavior for the ColorText class, but you need to keep the method name the same (AddColorText) public interface IColorText { public abstract void AddColorText(string text); } public class RedColorText : IColorText { public void ...


3

It's important to understand that a single method may not be your "unit". To give a contrived example, if (for some reason) you created a class with public methods: Add(object key, object value); Get(object key); which just wrapped a private Dictionary, it would be inconceivable to test just one of those methods at a time, independent of the other. ...


6

Despite established wisdom in writing unit tests, Martin Fowler has said that his idea of a unit is generally "a bunch of closely related classes and treat them as a single unit. Rarely I might take a subset of methods in a class as a unit." So there's no real reason why you shouldn't be unit testing a couple of tightly related methods as one unit. ...


0

The most maintainable code is code that isn't there. So instead of adding to the LOC count, new code that 'reduces' the LOC count (even if slightly less maintainable when viewed in isolation) could make the total code-base more maintainable simply by reducing its size. Thus the primary rule for maintainable code: maximize DRY. Secondly, there is nothing ...


1

Is the path statically or dynamically generated? If it is dynamic, then you can maybe test for a specific path because there is importance in testing the calculation of the path. I like to reference the same string constants the app uses when possible - that's one way to help. But if it's static, well - what are you really getting by testing? I think then ...


2

Is it just a symptom of my previous classes depending too tightly on each other? Most probably yes. Although you can get similar effects with a rather nice and clean code base when the requirements change enough How can I avoid this kind of cascading refactorings in the future? Apart from stopping to work on legacy code, you can't I'm afraid. But ...


-1

I think you usually cannot unless you are willing to keep things as they are. However, when situations like yours, I think the better thing is to inform the team and let them know why there should be some refactoring done in order to continue more healthy development. I wouldn't just go and fix things by myself. I would talk about it during Scrum meetings ...


0

Solution: Git Subtrees After fidelling around with submodules, I found that git subtrees allow me to achieve what I wanted. I mainly used this page to learn about subtrees and followed the following procedure in order to integrate a submodule (submodule-repo.git) into the parent repository (parent.git) # Start at the root of the parent repository. Add a ...


8

From (the wonderful) book Working Effectively with Legacy Code by Michael Feathers: When you break dependencies in legacy code, you often have to suspend your sense of aesthetics a bit. Some dependencies break cleanly; others end up looking less than ideal from a design point of view. They are like the incision points in surgery: there might be a scar ...


1

...I refactored the project to add the feature. As said @Jules, Refactoring and adding features are two very different things. Refactoring is about changing the program's structure without altering its behavior. Adding a feature, on the other hand, is augmenting its behavior. ...but indeed, sometimes you need to change the inner workings to add your ...



Top 50 recent answers are included