Cocoa Crispies posted:

if software is easy why do you have to go to college for it

Zizzyx posted:

socracheese just a small piece of advice for you, if you don't want your fuckups being used to belittle you maybe you shouldn't post them

also maybe keep your opinions on math to yourself as well

vapid cutlery posted:

the worst part of programming is developing software yea

Panic! At The cisco posted:

i was working on something where calculating a convex hull of some stuff would of been kind of usefull but i decided i didnt care enough to spend time on it and noone else noticed

Panic! At The cisco posted:

i was working on something where calculating a convex hull of some stuff would of been kind of usefull but i decided i didnt care enough to spend time on it and noone else noticed

Panic! At The cisco posted:

i was working on something where calculating a convex hull of some stuff would of been kind of usefull but i decided i didnt care enough to spend time on it and noone else noticed

gucci void main posted:

detroit posted:

trying to make a website should i learn python or erlang?

detroit posted:

trying to make a website should i learn python or erlang?

detroit posted:

trying to make a website should i learn python or erlang?

trex eaterofcadrs posted:

sorry kid, it's true, every single person that i respect as a programmer will readily admit the human race is writing poo poo software at this stage of the game

detroit posted:

trying to make a website should i learn python or erlang?

detroit posted:

trying to make a website should i learn python or erlang?

Cocoa Crispies posted:

erlang is entirely the wrong tool

learn html

Zarithas posted:

haskell is a prerequisite for any kind of web programming nowadays

you'll have to write your own haskell -> coffeescript -> javascript compiler, but that's par for the course

Tiny Bug Child posted:

learn php i guarantee you whatever you want to do will be easier than in python

tef posted:

but yeah, assuming you don't have to do database stuff, user authentication, management,

tef posted:

unless it involves writing non-white-power software that supports unicode

MononcQc posted:

that's racist there's plenty of white people with funky characters in their alphabets

adaz posted:

There are 31 separate rules but a few major ones. I'll briefly go over the ones I understand.

1.) No compiler warnings/errors. Compilers are the things that turn the C programming language (which is more or less human readable) into the actual executable code used by the processors which isn't very human readable. The compilers have a large number of checks and warnings they can generate before compiling code as basic sanity checks. For your poo poo to make it into the codebase not a single warning or error can be thrown by the compiler even if that warning or error is, in fact, the compiler being wrong. This can be uncommon because the compilers with all their warnings turned on (And they have a LOT of warnings) are pretty hard to satisfy for some things. Most places are "compiles without any explicit errors and oh maybe this warning subset." The we don't care that its the compiler being wrong, fix it anyway is a check against people outsmarting themselves, i.e. believing its a compiler problem when in fact they didn't think of something.

2.) Every loop must have hard coded bounds. A loop is a programming element that, basically, says For <condition> do <something>. It's pretty common to have loops that say For all the things in this collection do X. Every loop must have a hard coded max # of times it'll iterate through (Fairly uncommon) to prevent an infinite loop even when such a thing should be impossible. For example, say I have a loop that says check the antennas (we have 2 antennas) to make sure they have power. Normally you wouldn't bother adding a bounds check on something like that (there are only 2 physical antennas!) but in this case you do no matter what to prevent the impossible - maybe a stray cosmic ray caused a bit to flip and now you have 8 antennas - from causing real problems.

3.) NO recursion ever. Which is really uncommon in my experience. Recursion is an element that can call itself. So say we have a piece of code that can add two numbers. Well, if it can recurse that means that same function can call itself (Adding two numbers) again if it wanted to. Again, trying to prevent an infinite loop, stack overflows (too much data waiting to be processed basically) and simplifying code complexity in theory.

4.) All tasks must communicate through an IPC form. IPC is inter-process communication. A process is basically a single element of a program, say in a spacecraft a process could be the part of the software that watches the fuel pressure/temperature. So if it's checking the amount of pressure in the fuel tanks it should report that information via some defined IPC form rather than directly modifying the FUEL_PRESSURE variable or whatever in the engine control software. With IPC you would do something like call a method on the Engine Control Software called UpdateFueldPressure or something and let the engine software handle updating its own data. This prevents some rogue element from corrupting your engine control routine and allows the engine routine to check all inputs for errors.

5.) A bunch of rules on tasks/task delay/and use of semaphores. Basically designed to avoid race conditions and data corruption. Makes coding much harder but prevents an enormous amount of bugs, even if for them to occur would be "nearly" impossible (sensing a theme?)

6.) No GOTO statements. This is basically a universal rule of programming anymore - most modern languages don't even have a goto statement - goto breaks control flow and destroys code clarity. So a typical program might look like this:

code:

1  If($variable equals 0){
2    $isPressured = PressurizeEngine()
3    if($isPressured equals True) {
4      ShutDownThrusters
5     }
6  }Elseif($variable equals 1) {
7    RotateThrusters()
8  }Else {
9    If($variable equals 5) {
10     FireThrusters
11   }Else {
12     ERROR
13   }
14 }

Ok it's a mildly terrible example (we're nesting too many calls), but the idea is that if a variable equals some value we execute some engine control function. But say we add a GOTO in that.

code:

1  If($variable equals 0){
2    $isPressured = DePressurizeEngine()
3    if($isPressured equals False) {
4      ShutDownThrusters
5     }
6  }Elseif($variable equals 1) {
7    DoSOmething else
8  }Else {
9    If($variable equals 5) {
10     FireThrusters
11   }Else {
12     GOTO 3
13     ERROR
14   }
15 }

SO now if the variable doesn't equal 0,1, or 5 we return an error code but oh wait, before that shutdownthrusters by going to line 4. Oh crap! they aren't depressurized *engine explodes*. GOTOs bypass all your normal sanity checks and make everything a nightmare.

7.) Limited scope of variables. Scope is basically what has access to what data. It's tempting when making a program to just declare a ton of "global" variables that everything in your program can read/write to at any time. This also means your program is going to be buggy as gently caress since all it takes is one misbehaving function and you can globally corrupt data for everyone. IT also leads to unreadable mess of code and limits the ability of the various code testing strategies to uncover bugs. Limiting the scope allows each function to hide its data from other functions easing development and fault detection.

8.) Check all return values. If a function (say my function is AddTwoNumbers(x,y) - which adds X + Y and returns the value) sends something back to you. You must check that number before doing anything with it. Basically a way of protecting against a function that is spitting out rogue data. It adds a lot of time to your code development if you're having to check every possible thing sent back to you.

9.) Each function checks its input values. In our example AddTwoNumbers would check the values of X & Y to make sure they fall in the bounds of the type before doing anything with them. Basically if X & Y are integers they can't be null or nothing and they can't be larger than the limit for integers as defined in your program. This prevents all sorts of errors and enforces the principle that each element in the software shouldn't trust anything sent to it by any other element, limiting the scope of fault when it occurs. Again, adds a lot of work for the programmers.

10.) Use assertions. I believe assertions work the same in C as other places, but they are basically statements that say, ok this poo poo should never occur in real life if it does send back an error code. Say we have a function that checks the temperature of the fuel. Well, when we preform an assertion on the input value and see that its reading a temperature of 2 million degrees that's a problem as its something that can never occur in real life. Assertions are designed to prevent errors because of values that shouldn't ever happen but wouldn't necessarily be caught by rules 8 & 9 (which often times just check for null values or data that is outside the range of the type).

The rest of it is mainly rules designed to enforce code clarity and makes sure you don't do a bunch of really nifty cool poo poo that nobody else will be able to understand easily. However that really nifty cool poo poo often makes the programmers life much easier.

The general idea is that each part of code shouldn't trust any other part of code whatsoever, the impossible will happen and you MUST code for it, and nothing that can cause race conditions/infinite loops/stack overflows can ever occur.

Mr Dog posted:

If you need explicit coding standards then your development team consists of either idiots or prima donnas, congrats

(it is very hard to find programmers who aren't one of the two, i'm a huge prima donna myself )