Tag Info

New answers tagged

28

They already have a term for that in the Javascript world. They are called Immediately Invoked Function Expressions (IIFE). What it is IIFE functions are not given a name. Instead, they are executed once as the interpreter comes across them: var area = function() { var width = 3; var height = 2; return width * height; }(); The final ...


3

When I use TODOs (and FIXMEs), I tend to write them as questions, rather than statements. For example: // TODO: Can we ignore the negative case? // TODO: Is this premature optimisation? // FIXME: Is there a more robust alternative to parsing the version number? // TODO: Is it worth extracting this to a separate module? There are a few reasons for this: ...


-1

In anycase I am not sure what to replace my TODOs. It frustrates me that when I see faulty or questionable code i cannot add a marker. It sounds like: You know of a limitation in your code. You do not have time to address it now. You need to check in your code now. You need to document that limitation so it can be addressed in the future. That ...


-1

You should never put rules on what should not be checked in. The day a PC trashes it's hard disk containing hours/days of coding that is not checked in for some obscure reason will be the day you change the rule. I will even check in code with syntax errors or code that just won't run (rarely but not never).


4

I'm very sceptical about TODOs. I think all too often they serve as a label that helps to pass procrastination as some sort of a disciplined approach. Therefore I'm inclined to side with your team and I'd advocate to refrain from using them other than solely for private use, which is nobody's business of course. It's all good and well in theory, but as ...


0

We find that the main reason people want a "todo" on a feature completed piece of code is to express an idea or future improvement to be made at some point in the future. The unfortunately consequence of this is that the todo explorer for many developers is used for active and in progress code. To overcome this we add XML comments above methods and classes ...


11

To begin with “TODO” seems great... Then people starts to check code in with them. Then after a few years, the checked in code has 1000s of “TODO” in it. At that point, they become worthless, as you can’t use a TODO to track own work in process in any code. Hence the common rule about not checking in TODOs into branches that are meant to contain ...


25

I think this discussion pivots around a few things, not solely on the TODOs in the comments of the code - but they how are used and what they are used for to begin with. Code checkins If you are using private working branches, then checking in code that has odd temporary comments and markers as personal pointers of your own thoughts may not be so bad ...


1

For Linux you have the Filesystem Hierarchy Standard defining conventions about files. Read also the Program Library HowTo. Actually, I believe that you should prefer shared libraries to static ones. Notice that a library makes mostly sense when it can be reused by several applications. Otherwise, it might not be worth making a library (e.g. for some code ...


0

Not using self will make you think twice any time you use a variable. IMHO writing clean code is a matter of style. The style in Objective-C is to use self with properties. Since the vast majority of Swift programmers come from Obj-C, this style should be kept.


-2

Does your team use an IDE? Then just use the auto-indent feature if it has it. Most IDEs will have it, and you could even use a common configuration. e.g I do all my indenting in Eclipse with a Ctrl-I. I do not have to count spaces or tabs, and the code is very readable. (We have tried using the Eclipse Java code-formatter, but we gave up) ..and ...


-2

Does it even matter? See some questions on SE getting awfully hung up over ridiculous, irrelevant matters. Extensive questions following extensive answers into things that really aren't worth the time or effort. In some IDEs, you might even undo all of your preferences the minute you hit Ctrl+K+D anyway (at least for VS). EDIT Since some people may ...


-2

Honestly – it so doesn't matter how big the indentation is exactly. Personally, I tend to use only 2 spaces for imperative languages, but though I find it ugly I'm ok with anything up to 8 spaces. What you should of course aim for is that the indentation be consistent. Agreeing on a standard would definitely be a good idea. However, it's IMO not such ...


-2

If I'm editing existing code I tend to adopt the style of that code if someone else is working on it or is likely to come back to it in the near future. If the 'offending' coder is long gone then I will often 'tidy up' if the style is particularly 'weird', but to be honest bad style is somewhat correlated with bad code, so I usually have a good motive for ...


19

Use tabs. this is what they were invented for. If you use tabs then the indentation can be set according to each's preference. You know the phrase "use the right tool for the job", tabs are the right tool when it comes to indentation. (edit: for the downvoters, imagine you go to a new company and they say "our coding standard which you must follow is ...


49

A development team should work as a team, not as a collection of individuals. One important part of this team cohesion is agreeing a common set of coding standards that all must follow. There's no right or wrong with such standards, but it is vital that all agree to abide by the majority or agreed consensus. So hold a group meeting discussion to agree an ...


44

Use a pre-commit hook so that all code gets formatted automatically on its way to repository, and have your IDE reformat the code to your liking whenever it's fetched from repository. It's probably doable, although I agree with @DocBrown - if you're professionals, you should be able to pick a compromise and not sweat over such details. You will encounter ...


92

You could use tabs to indent your code, then allow each user to customise their tab width. Alternatively, agree on a set standard and stick to it - there are far more important things to worry about in software development than tab width. That said, anecdotally most people use four spaces as standard.


0

Since the childList field is private, a method must be in MyContainerVO somewhere. However, if the functionality to convert a Collection of ContainerChilds into a Map, based on various keys, is a useful general purpose utility, I would make it a static method of ContainerChild. e.g. public static Map<String,String> ...


3

If putting the functions chronologically improves the readability of the code, it means that you are using functions wrong. The primary purpose of dividing the code to function is to reduce the amount of context you need to hold in your mind at any given time. (functions have other usages when you use recursion or higher-order functions, but that's clearly ...


1

You can't make a Java program without objects. Everything you instantiate is an object. The static methods you call are called on instances of the Class object of their class. But yes, it's generally a bad idea to use a single big class with just static methods. It gets terribly unwieldy really quickly. Rather than avoid the issue of learning object ...


3

For this particular problem, it's not terrible. What you're doing is basically scripting an import process, which is a fairly straight-forward imperative problem. Java maybe isn't the best tool for that job, but it's fine. An experienced programmer might create an intermediary data structure to represent the data going into the database to help should that ...


3

The point of object-orientation is not to count the user-defined classes and judge via "more == better". Instantiating an object is useful if you really do have multiple things in your problem field that have identical behaviour but a distinct identity. You saw how that works with streams: one reads from one source, the next one from another; reading and ...


0

I'm presuming that your focus is on initialization via output parameter vs. initialization via return, not the discrepancy in how construction arguments are supplied. Note that the first approach could allow Foo to be opaque (although not with the way you currently use it), and that's usually desirable for long-term maintainability. You could consider, for ...


1

One argument in favor of the "output-parameter" style is that it allows the function to return an error code. struct MyStruct { int x; char *y; // ... }; int MyStruct_init(struct MyStruct *out) { // ... char *c = malloc(n); if (!c) { return -1; } out->y = c; return 0; // Success! } Considering some set of ...


0

When coding in Java, one should try to make the usage of each object of mutable type match one of two patterns: Exactly one entity is considered the "owner" of the mutable object and regards that object's state as part of its own. Other entities may hold references, but should regard the reference as identifying an object which is owned by someone else. ...


1

Depending upon the contents of the structure and the particular compiler being used, either approach could be faster. A typical pattern is that structures meeting certain criteria can get returned in registers; for functions returning other structure types the caller is required to allocate space for the temporary structure somewhere (typically on the ...


18

Both approaches bundle the initialization code into a single function call. So far, so good. However, there are two issues with the second approach: The second one does not actually construct the resulting object, it initializes another object on the stack, which is then copied over to the final object. This is why I would see the second approach as ...


22

In the 2nd approach you will never have a half-initialised Foo. Putting all the construction in one place seems a more sensible, and obvious place. But... the 1st way isn't so bad, and is often used in many areas (there's even a discussion of the best way to dependency-inject, either property-injection like your 1st way, or constructor injection like the ...


0

You would typically want UI strings like this to be pulled in from a string table instead of being hard-coded in the source code, for localization and ease of updating. So the approach I would take would be to use the inputs to build a lookup key, so something like: var lookupKey = "SALUTATION_" + gender1 + "_" + gender2; var format = ...


2

There are two speeds in software: the time it takes to write/read/debug the code; and the time it takes to execute the code. If you can convince me (and your code reviewers) that the hashmap function is indeed slower than the if/then/else (after refactoring to make a static hashmap) AND you can convince me/reviewers that its called enough times to make an ...


8

Titles really belong in the database, but you stated you have no control over this. You have not specified a language tag but the syntax is in the C family, so this will be pseudocode that is almost C++: map<string, string> titles; titles.emplace("M", "Sir"); titles.emplace("F", "Madam"); cout << "Dear " << titles[gender1] << " " ...


3

ratchet freak's answer is quite a good idea if the sentences are all the same pattern, but with two insets, one each only dependent on gender1 respective gender2. Phil W.'s answer is probably the most flexible answer as it allows explicit control over the greeting, though he's quite correct it's a radical change. You might not have the data in that form. ...


17

Radical solution: Let the user specify their own title (from a predefined list that you provide). Your solution (as viewed through English eyes) only appears to cater for Lords ("Sir") and ladies; most men would be addressed as "Mr", most women as either "Miss", "Mrs" or "Ms", depending on their marital status and personal opinions. Then there's a whole ...


2

If your language allows you to do it, you can write switch(gender1+gender2) { case "MM": print "Dear Sirs"; break; case "MF": case "FM": print "Dear Sir and Madam"; break; ... It's not necessarily better than your version, since there's still duplication, but it does avoid the nested switch.


29

Add the title to the parameters of the printf: char* title1; switch(gender1){ case 'M': title1 = "Sir"; break; case 'W': title1 = "Madam"; break; case ...etc. } char* title2; switch(gender2){ case 'M': title2 = "Sir"; break; case 'W': title2 = "Madam"; break; case ...etc. ...


1

You are declaring a local scope function in this case. This means it will only be available withing your scope which is very limited. If you are not planing to reuse it, I wouldn't declare a function all together. if you are planing to reuse it, I would move it outside the callback scope into a separate module/class depending on what the responsibility of ...


2

There’s no such thing as information overload, only bad design. — Edward Tufte It's a general rule in graphic design to leave out unnecessary elements and ornamentation to reduce noise. Fewer visual elements on the screen means less work for our brains to parse the actual useful information. let foo = 1 vs. let /* variable */ foo = 1; // EOL ...


2

This sort of thing can always be done with an IDE. I am not familiar with an IDE that supports this exact formatting, but I know that most modern IDEs have highly customizable settings for formatting code. As a Java programmer using Eclipse, I have it set so that I can type Ctrl+A(select all) Ctrl+Shift+F(code-format) and it will prettify all my Java code ...


3

In general, in Python I favor using functions over subclassing internal classes. In the end, if you write your String -> dict method, you end up working with a dict, pure as the driven snow. Just put your functions in a sensible module and import them only where needed; this will also encourage you not to import the functions everywhere, which will help ...


1

Should I provide these methods or should I let people implement their own? You should avoid doing that. Stephen Toub explains why in his article Should I expose synchronous wrappers for asynchronous methods? The reason why is that doing this has quite a few pitfalls, simple .Result may appear to work for you, but may fail (or rather, deadlock) in other ...


0

The reason for using prefixes is that they let you determine immediately whether an identifier refers to a local, global, static, or member variable. Not being able to do this makes code hard to read and hard to write without bugs. However, member variables only have this problem if you use them within member functions. If you didn't do that (or if you ...



Top 50 recent answers are included