Author Topic: Programming Megathread  (Read 106433 times)

woo i started a holy war

anyway i made a program a while ago in C++, maybe someone could take a look at it and tell me what i can do better (general practice-wise, not necessarily method-of-solving-the-problem wise)

http://dpaste.com/1M7Z5PB

edit: it's a program to solve http://www.infoarena.ro/problema/muzeu
works perfectly, i can translate the problem if you need it
« Last Edit: January 26, 2016, 12:00:56 PM by Tudoreleu »


I can not believe that I just read this

"I would never hire such an open source freak, because i would fear he spents his work time on other things, and discloses company work outside or take company sources and starts an open-source-project with it. We want to live from our work, and get money for our hard work. I never understand these open-source people, why they give away hard work for nothing only to be famous to other nerds.
If you have to offer something valuable, you deserve money for it. If no one will pay, it's simply not worth your efforts.
They destroy markets without any sense, i will never assist such people. I should pay them money, and they spent it to kill markets - never ever. Go to north corea, they need such willingly morons"

woo i started a holy war

anyway i made a program a while ago in C++, maybe someone could take a look at it and tell me what i can do better (general practice-wise, not necessarily method-of-solving-the-problem wise)
in general, you should actually avoid using the "using namespace std" or "using namespace" entirely, for that matter. if you use a function that happens to have the same name as one in std (such as list, string, etc.) then the compiler takes the std version of that function first, leading to very hard to find bugs. it's safer to just prefix all functions in std with "std::"

there are 100 reasons this is completely ridiculous, but most importantly is the fact that command prompt/terminal/console/whatever you wanna call it windows are usually 80 characters wide. I don't know why, but that's how it is, and to my knowledge most people keep it that way. with spaces you can make sure they'll be able to see all of your code without moving to their mouse to resize the window or scroll right. with tabs, you can not
Yes, because everyone uses the console window to code.
Name 10 out of your 100 reasons as to why we should still be capped at 80 width.
(Hardmode: no reverse compatibility reasons)

You seem to be completely ignoring the reason for tabs. The point is that you can customize the displayed width of them in the editor you use.

there is no increment operator in python, you have to use x += 1 instead
also, for loops in python give you the item in the list, not the indices. so instead of for z in name2 you'd have to use for z in range(len(name2)), where range is a function that returns a generator that generates a "list" using integers with a length equal to the argument, which in this case is the length of name2
so range(10) generates "0, 1, 2, 3, 4, 5, 6, 7, 8, 9"
range() also has more functionality but that's irrelevant right now
Hey, thanks for clarifying this. I think I said this already, but I'm not a python guy. 😛

Also, gonna plug this thing my friend made/is making: http://alicorn.io
« Last Edit: January 26, 2016, 02:20:53 PM by BluetoothBoy »

i just noticed there isn't any torquescript in the op which is incredibly strange considering that this is a forum for a game that uses torquescript
this is a hello world for ts:

Code: [Select]
echo("Hello World!");

i just noticed there isn't any torquescript in the op which is incredibly strange considering that this is a forum for a game that uses torquescript
this is a hello world for ts:

Code: [Select]
echo("Hello World!");
Which, coincidentally, is a hello world for a lot of things. XD

in general, you should actually avoid using the "using namespace std" or "using namespace" entirely, for that matter. if you use a function that happens to have the same name as one in std (such as list, string, etc.) then the compiler takes the std version of that function first, leading to very hard to find bugs. it's safer to just prefix all functions in std with "std::"

oh yeah

that's something i'm doing for now, at least until i actually learn about other namespaces

Yes, because everyone uses the console window to code.
um, plenty of people still use emacs and vim
even for people who don't, preferring the command line to a gui file browser isn't uncommon

um, plenty of people still use emacs and vim
even for people who don't, preferring the command line to a gui file browser isn't uncommon
Are you implying vim and emacs are restricted to 80 width? Because they're not.

Are you implying vim and emacs are restricted to 80 width? Because they're not.
they are used from the command line... which is by default 80 columns wide
the only time they'd ever need to change it is someone not following decent style conventions

they are used from the command line... which is by default 80 columns wide
the only time they'd ever need to change it is someone not following decent style conventions
What "default" are you using? Barebones linux distros scale properly to the monitor. Providing more than 80 char width for not terribly old monitors

What "default" are you using? Barebones linux distros scale properly to the monitor. Providing more than 80 char width for not terribly old monitors
I mean like this


loving QuickBooks Online API
Whoever wrote this stuff doesn't have enough English skills to give descriptive error messages that makes sense
"Can not instanti specified is unsupported or invalid"
pls
God damn
So the problem was that I had to specify the invoice's tax details.
Even though I was updating an existing invoice with tax details already specified, and I was using a "sparse" update, which according to Intuit's API documentation, is supposed to only update the fields I specify, and leave everything else alone.
But really though, is one thing to make a mistake, but none of this would be a problem if they could write sensible, descriptive error messages with understandable English