|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On December 16 2015 14:00 Shenghi wrote:Show nested quote +On December 16 2015 02:07 WarSame wrote:I've been doing some work on the number of different ways to make change, and I've almost got it working properly and running extremely fast, but got a strange bug - for a coin denomination it will run it with the max of that coin, then skip the second most possible and go straight to the third and on. I have no idea why, and can't seem to bug hunt it. The code is here. coinDenoms is a global variable. This outputs + Show Spoiler +There are 30 different solutions.
2 0 0 0
0 5 0 0
0 3 4 0
0 3 2 10
0 3 1 15
0 3 0 20
0 2 6 0
0 2 4 10
0 2 3 15
0 2 2 20
0 2 1 25
0 2 0 30
0 1 8 0
0 1 6 10
0 1 5 15
0 1 4 20
0 1 3 25
0 1 2 30
0 1 1 35
0 1 0 40
0 0 10 0
0 0 8 10
0 0 7 15
0 0 6 20
0 0 5 25
0 0 4 30
0 0 3 35
0 0 2 40
0 0 1 45
0 0 0 50 As you can see, it goes straight from 2 quarters to 0 - and I have no idea why. If you can point it out to me I'd appreciate it. Do you have the full code, so we can just paste it into an editor and it it works, without having to piece things together? That makes it a lot easier to help. =] Also, I asked this before (but not in a post that directly quoted you) and it's a very important difference: Is the question how many ways there are to make change, or which ways there are? This is important because if you take common coin denominations (1, 2, 5, 10, 25, 50, 100, 200), there are over 5 000 000 ways to change 500 cents and over 260 000 000 ways to change 1000 cents. While it's extremely easy to calculate how many ways there are, even for values much larger, it quickly become infeasible and slightly later impossible to determine which ways there are.
Sorry, there's a lot of posts in here so I must have missed yours. The full code is here. There are 2 classes - my main and the used class.
I want to show each way to make change one time - so a list of the coin combinations. Even for my relatively efficient current code, going to 1000 cents slows to a crawl. Is it that much faster if you're just counting number of ways to do it?
|
On December 16 2015 16:03 WarSame wrote:Show nested quote +On December 16 2015 14:00 Shenghi wrote:On December 16 2015 02:07 WarSame wrote:I've been doing some work on the number of different ways to make change, and I've almost got it working properly and running extremely fast, but got a strange bug - for a coin denomination it will run it with the max of that coin, then skip the second most possible and go straight to the third and on. I have no idea why, and can't seem to bug hunt it. The code is here. coinDenoms is a global variable. This outputs + Show Spoiler +There are 30 different solutions.
2 0 0 0
0 5 0 0
0 3 4 0
0 3 2 10
0 3 1 15
0 3 0 20
0 2 6 0
0 2 4 10
0 2 3 15
0 2 2 20
0 2 1 25
0 2 0 30
0 1 8 0
0 1 6 10
0 1 5 15
0 1 4 20
0 1 3 25
0 1 2 30
0 1 1 35
0 1 0 40
0 0 10 0
0 0 8 10
0 0 7 15
0 0 6 20
0 0 5 25
0 0 4 30
0 0 3 35
0 0 2 40
0 0 1 45
0 0 0 50 As you can see, it goes straight from 2 quarters to 0 - and I have no idea why. If you can point it out to me I'd appreciate it. Do you have the full code, so we can just paste it into an editor and it it works, without having to piece things together? That makes it a lot easier to help. =] Also, I asked this before (but not in a post that directly quoted you) and it's a very important difference: Is the question how many ways there are to make change, or which ways there are? This is important because if you take common coin denominations (1, 2, 5, 10, 25, 50, 100, 200), there are over 5 000 000 ways to change 500 cents and over 260 000 000 ways to change 1000 cents. While it's extremely easy to calculate how many ways there are, even for values much larger, it quickly become infeasible and slightly later impossible to determine which ways there are. Sorry, there's a lot of posts in here so I must have missed yours. The full code is here. There are 2 classes - my main and the used class. I want to show each way to make change one time - so a list of the coin combinations. Even for my relatively efficient current code, going to 1000 cents slows to a crawl. Is it that much faster if you're just counting number of ways to do it?
Not a problem. =] You can find Blisse and myself having a short discussion about this topic on page 691 of this thread.
The problem with having to show each possible combination is that you actually have to generate each possible combination. Even assuming you generate a perfect search tree where no incorrect combinations are ever tried (which is difficult enough, if not impossible, in itself), then you would still have to actually read and output each of those 260 000 000 combinations (in case of my earlier example, for 1000 cents). For time estimation it's usually fair to assume 100 000 000 operations per second, although (especially display) I/O is much slower.
In comparison, to determine how many combinations there are, all you need are D * V additions, where D is the amount of denominations and V is the value. For my example with 1000 cents, those would be 8 * 1000 additions. That is much, much cheaper than generating every possible (valid) combination.
Having said that, I'll be happy to help you look at your current code and help you find ways to improve it and find the bugs. I'll have a look after work. =]
|
Hey guys, what are your thoughts on app directory structure for large apps ?
We're (same team as here http://www.teamliquid.net/forum/general/134491-the-big-programming-thread?page=665#13295) still having a hard time agreeing with each others, especially me apparently, so I'd like some outsider's opinion.
So far, we were working in a packages based architecture, where every feature of your app has its own dedicated packages where everything concerning said feature is put.
Some other dude showed us angular, so we tried switching to that, but now for some reason they want to stop working with the previous architecture and use a simple client/common/server folders instead. We are planning on building a large app and going open source so I can't see how it makes sense, but they find that easier to work with.
At that point I'm considering just moving on with them and working on my own, or at least in the way I think is best for the project, whether they follow or not. Seems extreme though, kind of a knee-jerk reaction, but I'm getting really tired of argumenting with them, them changing their minds, and the project not moving forward one bit for the past 2 months.
Thoughts on any of this ? Am I according too much importance to this "good practice" stuff again ? Am I simply wrong on what's best ? Since there was a debate about factoring code where they both thought it was pretty much useless, I'm not sure it's a good idea to still try to work with them anymore, seems to have caused mainly decisions that brought the quality of code down, while not providing any more productivity...
Edit : Might be useful to add that we're all 3 students, no one is particularly more experienced than the other, but I'm way more invested in the project we're working on, intend on working on it for a long time, and expanding it a lot. This doesn't hold true for them, they will probably be gone in less than a year. We're not employees, all 3 independants working together, so no one has any obligation to work for anybody here.
|
On December 16 2015 19:56 Cynry wrote:
*snip*
So far, we were working in a packages based architecture, where every feature of your app has its own dedicated packages where everything concerning said feature is put.
Some other dude showed us angular, so we tried switching to that, but now for some reason they want to stop working with the previous architecture and use a simple client/common/server folders instead. We are planning on building a large app and going open source so I can't see how it makes sense, but they find that easier to work with.
*snip*
It is always better to split stuff now and then combine it later if needed than to have stuff combined now and figure out how the heck to split it later if parts, but not all of it, are needed in a different part of the application or in a new application.
However, it all depends on the actual definition of feature and package in your project. If you split it up too much, you can easily end up doing more work than needed and you have a lot more dependencies between your modules, which can make it harder to work with the code later. It's a balancing act that requires experience.
In the end, speaking as more of a project manager than a programmer, you are now in a situation where you can either refactor or not and, since you are all inexperienced, the best way to go is to not refactor no matter how ugly all programmers think the code is and get the project out of the door. Once the project is finished and you have learned dozens of new lessons on the way, you can refactor the stuff and make it right, but if you don't even have a finished project, you won't ever know if the way you chose was the right way. Finish the project, learn what eventually turned out to be wrong and what turned out to not actually matter at all, only then can you do it better next time.
Refactoring is infinite, project schedules aren't.
|
Dunno man, what you're saying makes sense, I'm just tired of agreeing on coding dirty stuff (yeah sure, we can't know for sure what's good, but at the very least doing the way different people agree on being the best for bigger app is a good start I think) just for the sake of finishing the project, when the people I'm trying to keep working together barely work to begin with.
There's probably a lot more on this issue than just the architecture though.
I'm ok with just winging it and moving forward, but we're gonna have client looking into the code 2 weeks from now, we already have a long list of potential customers (and freaking big ones) so I don't see an easy time to refactor later. How would your project manager side would make all that work ? 'Cause for all my inexperience, I'm still the closest thing to a CTO we have, so I'm really interested in anything you could say to help managing projects and people...
Also told the board we agreed on something clean, because that was still the case monday. Doesn't help this mess either
|
On December 16 2015 22:28 Cynry wrote:
Dunno man, what you're saying makes sense, I'm just tired of agreeing on coding dirty stuff (yeah sure, we can't know for sure what's good, but at the very least doing the way different people agree on being the best for bigger app is a good start I think) just for the sake of finishing the project, when the people I'm trying to keep working together barely work to begin with.
There's probably a lot more on this issue than just the architecture though.
I'm ok with just winging it and moving forward, but we're gonna have client looking into the code 2 weeks from now, we already have a long list of potential customers (and freaking big ones) so I don't see an easy time to refactor later. How would your project manager side would make all that work ? 'Cause for all my inexperience, I'm still the closest thing to a CTO we have, so I'm really interested in anything you could say to help managing projects and people...
Also told the board we agreed on something clean, because that was still the case monday. Doesn't help this mess either
First things first, there will never be clean code. There is messy code and there is messier code, but you will never achieve clean code in any project that is actually intended to be released at some point, and a big reason for that is because people can never agree on what clean code actually is. What you think is clean today will look like a horrible mess 6 month from now, especially code that you wrote yourself to the best of your ability.
You are working with people that have no obligation to work together with you or do what you ask them to, so your best bet is to let them write the code they think is best, which means that they are more motivated and will get stuff done, while you write the code the way you like it. Separate your code from their code and whenever you modify their code, refactor it to a very limited degree to how you like it, just don't start moving classes around without need. Eventually they will leave the project and you can replace the code they wrote with better code, as long as their code is mostly separated from yours.
Your first priority is keeping them motivated to get stuff done and that doesn't work by telling them "You're doing it wrong". You have to make a compromise between giving them the freedom to implement their ideas, giving them the chance to learn from their mistakes, and making sure their bad ideas don't interfere with the better parts of the program. It's difficult to do that, but it's the only way you can keep them working on the project. If you try to force issues, they'll just stop caring and then you're either two programmers down or have two programmers that are so unproductive that they might as well not work at all. The first idea for code separation which you will most likely have is division of responsibility. Don't do that, it hurts motivation and productivity if someone only does X and isn't allowed to do Y. Ask them to make the feature code self-contained where possible, and you'll later be able to scrap the code of a feature and replace it with a better implementation while they still have the ability to implement features the way they want them - just don't tell them that that's your plan.
A client looking into your code is not a big deal. What clients look for are security concerns, not code quality stuff. 99% of all projects would never get completed if good code was a condition for it. As long as you don't have SQL injection, XSS or plain-text passwords, you should be fine for any review. I have seen the worst kinds of spaghetti code pass code reviews for payment partners that were far, far more serious than PCI. As long as your code is stable and secure, it doesn't matter if all your classes are called Alice and Bob. If you have other clients lined up, it's even more important to make sure your project reaches a finished state soon. If you are 80% finished, remember that that means you've only done 20% of the work and you still have 80% of the work ahead of you - and no, I'm not kidding with that one.
In the end, you will not be able to make them write code your way unless you pay them for it, so just make them keep writing code and try to contain the damage or you'll be on the project on your own - and then you'll probably never finish it.
|
I have to agree with Morfildur here. Up until very recently I was all boy scout, refactoring bad code whenever I had some spare time and I've noticed it while working on something else. All that changed when people started bitching about me touching their code that worked. No amount of "it's still working just as before except now we're not constructing XML by concatenating strings any more, which makes it more reusable and easier to work with (and doesn't look like total shit within the code)" was going to convince them.
Still, every time I come across recent code that's been written by an experienced developer but looks like some total newbie wrote it 15-20 years ago I die a little inside 
I guess that people learn a certain way of doing something and they'll keep doing it this way forever, even if it's not a good way.
|
On December 17 2015 07:04 Manit0u wrote:I have to agree with Morfildur here. Up until very recently I was all boy scout, refactoring bad code whenever I had some spare time and I've noticed it while working on something else. All that changed when people started bitching about me touching their code that worked. No amount of "it's still working just as before except now we're not constructing XML by concatenating strings any more, which makes it more reusable and easier to work with (and doesn't look like total shit within the code)" was going to convince them. Still, every time I come across recent code that's been written by an experienced developer but looks like some total newbie wrote it 15-20 years ago I die a little inside I guess that people learn a certain way of doing something and they'll keep doing it this way forever, even if it's not a good way.
I don't think it's a good idea to refactor code that you weren't going to touch anyways - unless you do it in a planned and communicated way. Fix bad code a little (don't go crazy, take tiny steps, and try to use safe, tool-assisted refactorings for the most part) before you modify/expand it. Also communicate this concept with the team. You won't get anywhere if you're the only one cleaning up. Just be careful how you talk your team into it. Use tiny steps here as well. If you try to change their mindset in one big swoop you're just going to face even more opposition.
|
On December 17 2015 07:47 spinesheath wrote:
I don't think it's a good idea to refactor code that you weren't going to touch anyways - unless you do it in a planned and communicated way.
This, this, so much this. I used to be the same way, and then eventually, I realized 'it's still working just as it was before' is literally never true. If you don't have a damn good reason to change something that isn't causing visible breakage, you're taking on non-trivial amounts of risk just to make yourself feel better about your pretty code.
That being said, sometimes you definitely do need to refactor - but I've moved far, far, far away from doing it 'just to tidy up'.
|
Yeah, well. It was agreed upon with the team beforehand that if we see crappy code (mostly stuff from old systems integrated into newer ones) we should fix it. When I stopped refactoring such stuff I kept getting comments in my commits like "What the hell man? You leave such crap in there? Not that long ago you'd totally rework it ". Got mixed and confusing communiques so I just stopped caring some time ago. I do my thing and leave the rest as is, even if it hurts me to do so.
|
On December 16 2015 09:40 tofucake wrote:
If it's on the PC you can do what you want in Batch
Thanks again to everyone who replied on my question.
In the end i managed to copy everything with a batch file.
move /-y "D:\Roms\*[i]*.smc" "G:\"
pause
*in explanation, this moved all the files in D:\Roms containing [i] in the filename to G:\, which is a usb drive.
Worked like a charm. ^^
|
On December 17 2015 09:01 Cyx. wrote:Show nested quote +On December 17 2015 07:47 spinesheath wrote:
I don't think it's a good idea to refactor code that you weren't going to touch anyways - unless you do it in a planned and communicated way. This, this, so much this. I used to be the same way, and then eventually, I realized 'it's still working just as it was before' is literally never true. If you don't have a damn good reason to change something that isn't causing visible breakage, you're taking on non-trivial amounts of risk just to make yourself feel better about your pretty code. That being said, sometimes you definitely do need to refactor - but I've moved far, far, far away from doing it 'just to tidy up'.
Here's the guys who know their shit :D While your fingers may be itching to tidy up someone else's code, just don't. It can break things that weren't broken, piss people off, and all you get out of it is neater code (in your opinion).
|
Did well with Google interview, bombed the first, did good on the rest. And then I missed my flight back home. Hate. Life.
|
|
|
On December 17 2015 09:01 Cyx. wrote:Show nested quote +On December 17 2015 07:47 spinesheath wrote:
I don't think it's a good idea to refactor code that you weren't going to touch anyways - unless you do it in a planned and communicated way. This, this, so much this. I used to be the same way, and then eventually, I realized 'it's still working just as it was before' is literally never true. If you don't have a damn good reason to change something that isn't causing visible breakage, you're taking on non-trivial amounts of risk just to make yourself feel better about your pretty code. That being said, sometimes you definitely do need to refactor - but I've moved far, far, far away from doing it 'just to tidy up'.
Yeah well we're far from 'just tidying up' anything here. From the respone I got here, it seems that everyone thinks I'm some kind of psycho-rigid refactoring maniac. And it might very well be true, but that's not what's happening now.
We were working on some file architecture that is said to work well for what we want to do for months, and now it's been 3 days since they said "well, why not rather go with this splendid file organisation that I found on a beginner tutorial". Deadline is in 2 weeks. Yeah this is what's happening. I'd be happy if I even had code to consider refactoring, but right now we have nothing to show at all, that isn't 2 months old.
Touching and breaking other's code without asking them ? Yeah there was some of that, but not from me. And I couldn't for the life of me even make him tell why he changed anything. He was even convinced that it worked better after he changed it. It didn't. That's the kind of bullshit I have to make do with, so yeah I'm lacking patience, and the urge to "keep the team together at all cost" is fading. They are paid, that are not delivering, arguing with them is tiresome and amnesia will make it worthless after some time anyway.
|
On December 17 2015 10:57 Acrofales wrote:Show nested quote +On December 17 2015 09:01 Cyx. wrote:On December 17 2015 07:47 spinesheath wrote:
I don't think it's a good idea to refactor code that you weren't going to touch anyways - unless you do it in a planned and communicated way. This, this, so much this. I used to be the same way, and then eventually, I realized 'it's still working just as it was before' is literally never true. If you don't have a damn good reason to change something that isn't causing visible breakage, you're taking on non-trivial amounts of risk just to make yourself feel better about your pretty code. That being said, sometimes you definitely do need to refactor - but I've moved far, far, far away from doing it 'just to tidy up'. Here's the guys who know their shit :D While your fingers may be itching to tidy up someone else's code, just don't. It can break things that weren't broken, piss people off, and all you get out of it is neater code (in your opinion).
I agree. The problem I'm facing however is that most people write the code with the thought that they won't have to look at it ever again. The thing is, they won't have to look at it but I will since most of the devs in my company are concerned only with the ongoing project and after it's released they move on to the next while me and one other guy have to not only work on ongoing stuff but also fix those previously released. This means that when most of our devs only work on one project at a time I have to work on 4-5 simultaneously (and I'll have to do this refactoring sooner or later so I'd rather do it sooner)... Sometimes life just isn't fair
|
|
|
On December 17 2015 15:54 Nesserev wrote:Show nested quote +On December 17 2015 15:25 Blisse wrote:
Did well with Google interview, bombed the first, did good on the rest. And then I missed my flight back home. Hate. Life. What was the whole process? Got any fun or memorable interview questions?
2 interviews in morning, 1 hr casual lunch with someone, 2 interviews after lunch.
really nervous with first interview, and the guy expected me to debug a stack frame. I learned all the parts before in my security class but totally blanked because of rust. He expected really good C++ skills and I was totally not thinking... also a coding question that i messed up the end condition on but sssh
next two interviews were straightforward, count the number of components in a linked list given a stream of nodes in the list that signify they are components, and then an open design and implementation question about determining if two people are blood related in a family tree.
the last one was a super open question about upgrading software on a bunch of servers on the moon.
|
I finally got a proper job as a C++ programmer a few weeks ago. Does anyone have any tips for learning and understanding large code-bases? I don't really want to keep having to ask other people how things work in the code base, but that often seems to be the quickest way.
I've also been experiencing the frustration of other people's bad code. I'd want to re-write certain things (and I have to change bits of it anyway), but it's just so hard to change anything without breaking other stuff that shouldn't even be relevant. It seems like the best (least painful and least time-consuming) choices I can make just isolate and remove my own code as much as possible from what's already there. Which doesn't really seem right. Maybe I'm just being too anal about things.
I suspect the only solution is to make damn sure that people only commit clean code to start with. Which I guess means having strict standards and conventions, and code reviews.
|
On December 18 2015 05:54 netherh wrote:
I finally got a proper job as a C++ programmer a few weeks ago. Does anyone have any tips for learning and understanding large code-bases? I don't really want to keep having to ask other people how things work in the code base, but that often seems to be the quickest way.
I've also been experiencing the frustration of other people's bad code. I'd want to re-write certain things (and I have to change bits of it anyway), but it's just so hard to change anything without breaking other stuff that shouldn't even be relevant. It seems like the best (least painful and least time-consuming) choices I can make just isolate and remove my own code as much as possible from what's already there. Which doesn't really seem right. Maybe I'm just being too anal about things.
I suspect the only solution is to make damn sure that people only commit clean code to start with. Which I guess means having strict standards and conventions, and code reviews.
If your not sure what something is/does, and you can't figure it out in 15 minutes, ask. The alternative is that you code missing knowledge of what something does, which will cause errors, or spend an excessive amount of time trying to figure it out yourself. A lot of the time it is something that can be explained in a short amount of time.
About bad coding styles, I've found that it is best to just follow the style of the code that you are changing, even if it is bad. It is better to have a consistent, but bad style/code then to have a patchwork of many different styles/coding habits. If your going to be changing it, you really need to change ALL of it at once, which is usually a massive task that won't ever get completed.
|
|
|
|
|
|
EPT
