Tag Info

New answers tagged

1

This depends on the domain. For laying out a web page it will work fine and you can get immediate feedback (you can even do it in the browser directly!). Similarly it would work well for anything that doesn't require a long time to initialize. This is preferred since it keeps your mental workload low and reduces the possibility of mistakes. However, for ...


0

As others have stated, this is definitely not a bad habit. I generally prefer to make only a few modifications at once. The only exception is if I have a large list of changes that don't all affect one another (e.g. changes to minor styles or copy, changes on different pages, etc). If you're modifying layouts, stick to making changes one at a time so you can ...


0

For any habit a developer has, there are 2 main questions: How does it influence the quality of the code you make? How does it influence your productivity? If the answer to both is "It makes it better", screw habit, teach it to others! If the answer to one is "Better" and the other "Worse" - it's a style and you have to be conscious about it. It's not ...


5

XML headers (e.g. <exception>) are the best way of drawing attention to exceptions in C#, as this information will appear in IDE when typing the function name, as well as in auto-generated docs. However you cannot force a user to deal with the exception since C# specifically avoids checked exceptions. Most people don't put exception information in ...


7

Your question has two parts: 1) Should I perform them all once and then test them together ? I assume you are using a VCS. And to track, what tasks were done it makes sense to distribute the list of tasks to a list of commits: one task, one commit. That makes it easy to manage different versions of the current code base; you could revert to a previous ...


56

It's a good practice. You are following the scientific method. If you change several things before any testing, then the testing of each will be more difficult, and perhaps not reliable, since preconditions will be more difficult to prepare and the different changes can interact between them in manners you didn't foresee. The time you feel you are "wasting" ...


17

Making lots of little changes and testing each one is not a bad thing. It allows you to see the effect of each change, and then when one change causes a problem, it's much easier to know which change caused issues - the most recent one! If you have a task list with 10 items, and you do all of them at once and then test the page and then notice that the page ...


1

For any given piece of code, there should be at most one place that is responsible for exhaustively testing that code. There can be any number that incidentally test it; you just don't want to waste effort running up an exponentially large mountain. For your example, the minimum set of test cases is a list of invalid forumulas, plus a list of valid ...


3

No, it isn’t necessary to remember every line of code. I am not a game developer but my advice is to be more concerned about the overall design and structure of a project. Plenty of developers reuse existing code, in one form or another - there’s no shame in that. BUT, copying and pasting code - without even attempting to understand how it works - isn’t ...


2

as long as it is ok that the app does not work when there is no networkconnection available (similar to a web-page) your app does not need to store additional info like "user has seen this info at 15:30" you donot need to implement a cache. if you want to cache the data for faster access why putting it into a database with complex datastructure? isnt ...


6

No, a unit test should test the thing it's targetting and nothing else. You're allowed to assume that any other method that this method calls does the right thing, because they must have their own unit tests. If one of those helper methods were wrong, you'd get an alert when that other test is run, and since you're supposed to run the entire test suite and ...


2

When using a complex framework or library, how can I avoid accidentally skipping a relevant part of the impenetrably huge documentation, therefore creating unnecessary work for myself? You can never know everything yourself. By exposing your code to others, you will have other people with other knowledge seeing how things are done and correcting you. ...


3

I am going to be overly critical. I don't mean this to be mean, but to provide the most accurate feedback I can: What are best practices when it comes to designing a social network app for Android (possible iOS port later depending on uptake)? Focusing on a specific platform for architecture is unwise. Mobile apps have their own foibles (is it ...


5

It depends on how well you want to understand the process. As a matter of general principle, you should never re-invent any wheel, unless you either Think you can do it better than the experts, or Are doing it for the learning experience. If your goal is to get a game released as quickly and economically as possible, you should leverage the work of ...


1

Holding configuration data like this externally to the application code is quite common. Since you have to persist this information somewhere a RDBMS is as good as anywhere, especially if the application is using the DB for "real" data already. Having five tables for your putative five levels of menus is not a good idea. It is inflexible and you can ...


4

Your menu is essentially a tree, so could be stored in a single database table: ID (number, not null) PARENT_ID (number, can be null) DESCRIPTION (text) where PARENT_ID is null for top-level menu items. You might need one or more additional columns to hold the behaviour you want to associate with the menu items (e.g. an action ID, command name or URL).


0

final fields have many benefits! Declaring fields as final has valuable documentation benefits for developers who want to use or extend your class - not only does it help explain how the class works, but it enlists the compiler's help in enforcing your design decisions. Unlike with final methods, declaring a final field helps the optimizer make better ...


3

Feedback is crucial to maintaining this relationship I'd advocate for a more collaborative approach to help you work better together with these vendors. If you value the closeness of this relationship, and want to keep it, open lines of communication that help them serve you better are best. Consider the fact that almost nothing works perfectly once it is ...


0

It is completely appropriate to refuse to release company code (as intellectual assets as the business lawyers would call it) to anyone. Just refuse, and blame the legal team. Your IP is what makes your software company, give it all away and don't be surprised when you find a competitor springing up doing remarkably similar work to you... Payment... ...


1

"commons" or "util" are normally used for shared code between different parts of a complex project. And off course are a very good example of bad naming and laziness and normally end up as a bag for crap. What type of things you can find inside a common library in a project?, who knows!, surprise me!.


1

commonly used While writing code, one often finds themselves with a common set of tools/classes/libraries that are used again and again across multiple projects. The other classic name for this is 'util', but 'util' classes are sometimes seen as an anti-pattern. Even though thats what these are, such a name can sometimes set off a developer's anti pattern ...


19

Writing code is only a part of the interview process. Actually solving the logical problem is only a part of the code writing task. Interviewers want to be sure that: You can write code. Many candidates with ten years professional experience in a language can't write any code at all, and this test is intended to reject those candidates. You think about a ...


1

You cannot use HTML and AJAX on its own to access your databases or data stored on remote/hosting server. You will need a server side scripting language PHP, ASP, PERL, CGI, etc. HTML and AJAX run on the "client side", the computer accessing the web page. The server side languages run on the "server". HTML can invoike AJAX to access a server side script ...


3

Login using AJAX, jQuery and PHP: http://stackoverflow.com/questions/14449118/php-ajax-login Personally I think PHP is barbaric. The only acceptable use is if you're using a framework like CakePHP or Laravel. My preference is Django Python or Node.js. But there is no disadvantage to which backend you use. Each language has its strengths and can perform ...


14

At runtime, it does not make a difference. The point is readability - as a member variable, it likely is declared at the beginning of the class' source code, and making it static means it doesn't have to be allocated for each new instance of the class. Making it final signifies to the reader that the value will not change (to the compiler too, but that's ...


0

Presuming your app can be built from the command line given a clean checkout and pre-requisites preinstalled you can mechanically do it with something as simple as a cron job or scheduled task. But what you really want here is known as a continuous integration server. These servers handle a couple of things: they make it easy to orchestrate the "go build ...


4

A build machine is the way to go, even for small projects/teams. Get any random spare machine (ie. an old dev box). Install some continuous integration software on it like jenkins or teamcity. Done It's been a while since I had to set one up or maintain a build machine, but unless it's gotten worse since a year or 2 ago, you can have continuous builds ...


-1

In the case of refactoring, for example: Refactoring takes time. Time costs money. Therefore, refactoring is only worthwhile if you get benefits from it that outweigh the refactoring cost. Just after you have created a kind-of-working solution, that's the time when refactoring is cheapest (because you know the code inside out at that point), and can give ...


-2

Two more suggestions, I'll bet at least one of these you haven't done. 1) Put a bug tracker in place and teach your boss to use it. This can be part of the conversation about how you screwed up, have learned better and are going to fix it in a planned manner 2) Start using version control, although hopefully you are doing so already. There are heaps of ...


4

I'm not sure how far you've got with your design. Your description of "hole-punching" does not ring exactly true. AS I understand it, the server has no need for client IPs except when they are on-line and available for connection. Each client connects to the server, thereby providing a current IP location and NAT channel. A user wanting to call another user ...


7

Then don't. They are expecting you to do more. Given free reign, a set of data, and a customer, you should be able to come up with something relevant and useful. If nothing else, you should be able to curate the data into a well-formed database, so that when someone has a question to ask about it the answer can be easily retrieved. (Being able to ...


0

Peer-to-peer connections don't play well with firewalls. Connections though an external server or proxy, play much better with firewalls. As long as you are providing IP addresses for the connection, I believe you will risk leaking client IP address(es). Allowing the clients to switch to a peer-to-peer connection after establishing a connection may help ...


-1

Your question says: "Started wrong, should I start over" while the additional text actually says "Finished project, but did it wrong, should I start over". For the question headline alone: If the amount of programming work that you have done is small compared to the total work needed, then starting all over will make sense. That happens a lot when the ...


-2

You're a beginning web developer, with no good developer present to advice you, your boss hired you knowing this fully well. I think you are doing just as well as anyone could expect you to do. Actually, the fact that you have the insight that the job could have been better, and that you actually learned things that would allow you to do it better, means you ...


0

Throwing everything away is usually a bad idea. Rewriting parts of the system may be a good idea. Refactoring is often a good idea. The way I see it, the question is not whether the code is good or not. Code you wrote more than a week ago is always a terrible mess because you have since learned something new which you wish you had used. The question is ...


1

Your question has two major concerns: should I write good code, even if the next person may not understand it? and, how to I make sure that my efforts are not wasted if a less experienced person takes over after me? As to the first, you should always write the best code you can. We know that code written with design patterns and principles is flexible, ...


4

This is fundamentally a cultural issue. First of all, be careful of thinking you can "prove" that a different methodology is better. With time and experience, you'll get better about "persuading" your colleagues about better practices. The problem is that the people in a shop develop certain habits, and come to certain shared understandings, and become ...


0

In your example, iStream actually gets closed in processStuff(), not a copy. I would recommend, however, always closing the InputStream in the same method where you created it, otherwise it's difficult to understand whether it is closed or not. The call to close() should be in a finally { ... } clause so that for sure it is called, even if an exception is ...


7

There are two things of note here: you seem to know quite a bit about good practices and the project is meant to disappear "soon" (though not right after you leave). As Telastyn mentions, make the most out of this experience to learn what works and what doesn't and how to apply best practices in a real-world environment. Think about yourself first. That ...


6

The point of an internship is to learn. I would refactor the code to be better and ignore the assumed limitations of people you don't know. For all you know, the company will move that project to an internal team rather than interns soon.


8

Objects that are passed around to other methods can be changed by the method, and the caller will notice the change. If you let someone else use your Stream, they might close it and you'd never notice until you try to write and fail. That's why it's usually a good idea not to pass mutable objects around outside your control. Confusion often arises because ...


0

This is what I would do personally: Quit, make an excuse and give up (you can even give back part of your salary so you don't look bad) Clean your code as much as possible Make documentation on all the good parts of your work like your good design, good ideas, etc... Why do I suggest all of these to you? Because think about the future. There will be ...


4

For reasons that others have thoroughly explained, it is time to finish the project and ship it, painful as that may be. I would just like to emphasize that testing the app is also part of "finishing" it. If significant pieces of functionality haven't been thoroughly exercised and correct results confirmed, then you're justified in your concern that people ...


-1

To answer your question: as so many others have said, no. Ship it, and clean it up bit by bit in the process of fixing bugs. Additionally, while books/StackExchange/webforums are good learning resources, you are likely to find that nothing can match the learning you will receive from working (or even just discussing work) with other programmers. Finding and ...


6

Most of what I would say in response to your question has been said by others. Read "Things You Should Never Do, Part I" by Joel Spolsky (along with some of his other posts about "architecture astronauts"). Remember that "the perfect is the enemy of the good". Learn to refactor incrementally. Shipping is important, etc. What I would add is this: you've been ...


6

I have been told that a good practice for writing methods is to make the method only responsible for doing one thing. The common problem people have with this is that they take it too literally. If a function can only ever do one thing, how do you ever do more than one thing ever? If your "one thing" takes 5 steps, then make a single function that ...


2

As far as I know, declaring a helper method as a lambda like this is not commonly done in C#, so I would advise against doing this unless you have a good reason. Good reasons include: The lambda could do something a separate method can't, like closing over a local variable or using anonymous type. Others in your team agree with you that this is a good ...


9

You're doing good. You say that your code works, and it's almost ready to ship, right? And you perceive that your code may be vastly improved. Good. Your dilemma much reminds me of my first experience with freelancing (getting hired while in my 2nd year at uni to create a multilingual POS system). I went through endless questioning as I was never satisfied ...


21

I forget where I first read it, but I just wanted to echo, somewhat more forcefully, what other people have said: Shipping is a feature. There is nothing worse than that one guy who keeps "cleaning up" existing (possibly hacky, ugly, dirty) code that works perfectly well, introducing new bugs, etc. What matters in the real world is getting your job ...



Top 50 recent answers are included