does anyone do programming on college or whatever?

[2justin9]

how to create flowcharts for the process for instance


one acre of land = 45 356 square feet design a program that ask the user to enter the total square feet in a tract of land and calculates the number of acres in a tract

hint divide the amount entered by 45 356

can anyone?

 

[WolfHaley]

You forget to cross multiply.

 

[2justin9]

thats not the answer its the question

 

[reizon]

you don't know how to create a flowchart.??

well damn that's as dumb as they come.!!

FIRST take input parallelogram

use input in formula, with reactangle, process box

display output with parallelogram.!!

I don't think there is any decision boxes required, but then again I don't read the question very well.!!

Just gave you basic knowledge on flowchart symbols only.!!

 

[minatofan234]

im not at college lv yet but since your in college and im assuming you are why not ask around campus?

 

[itachi uchiha fiance]

hey u mean progrm in java?

 

[2justin9]

no this is intro to programming this is due for tomorrow so im screwed gues im pulling an all nighter

 

[itachi uchiha fiance]

hey my q is clear . I am asking u that u require ans in programing language ??? If yes then msg me q in detail

 

[2justin9]

no i dont its not in java im doing introduction to programming 1st so it must be done on paper

 

[Douryoku]

hey my q is clear . I am asking u that u require ans in programing language ??? If yes then msg me q in detail

It's pseudo-code.​

​

 

[EnDash]

i hate flowcharts, they are for EA and microsoft employees...

this one is pretty simple and should be something like this:

| Get Input |
_____|
| Divide Input By Size Of One Acre |
_____|
| Present Result As Output |

here is the code in c (i just wrote it so it may have compiler errors)

Spoiler

#include <stdio.h>

int main()
{
printf("Please enter tract size: ");

int input, output;
int oneAcre = 45356;
scanf("%i", &input);

output = input / oneAcre;

printf("There are %i acres in that tract", output);

return 0;
}

to be frank, i never use flowcharts or pseudo code, i find that i design a program better with the code in mind then in other forms.

 

[EnDash]

....................................

i fixed it the code, thanks.

 

[Aim64C]

Flow mapping programs is more useful for programming teams and larger segments of dynamic code.

Most bugs are caused by programming teams simply not communicating or convicting themselves to naming conventions. Then you get a million and a half lines of code of WTF that you then layer script parsing on top of.

Then you have production managers say: "Oh, it will be okay. We'll have a patch ready by launch day, right guys?"

"Uh... no... we won't."

"I'm sure you guys will fix most of the big stuff."

"Uh... we can make the program launch, run a little bit, and exit without ctrl+alt+del being involved. There still exist substantial script handling issues, not to mention the mechanics of the game..."

"Right, so we'll just patch those up after launch."

Flow charts are a good way of showing what resources need to be utilized by what processes (particularly within multi-threaded environments) and establishing those naming conventions.

Unfortunately, the number of people who know how to use those things even remotely effectively are few and far between. So you usually end up with death-by-power-point.

 

[EnDash]

Flow mapping programs is more useful for programming teams and larger segments of dynamic code.

Most bugs are caused by programming teams simply not communicating or convicting themselves to naming conventions. Then you get a million and a half lines of code of WTF that you then layer script parsing on top of.

Then you have production managers say: "Oh, it will be okay. We'll have a patch ready by launch day, right guys?"

"Uh... no... we won't."

"I'm sure you guys will fix most of the big stuff."

"Uh... we can make the program launch, run a little bit, and exit without ctrl+alt+del being involved. There still exist substantial script handling issues, not to mention the mechanics of the game..."

"Right, so we'll just patch those up after launch."

Flow charts are a good way of showing what resources need to be utilized by what processes (particularly within multi-threaded environments) and establishing those naming conventions.

Unfortunately, the number of people who know how to use those things even remotely effectively are few and far between. So you usually end up with death-by-power-point.

yes, for architecture and system design flow charts can be very helpful, but i don't think that for small programs and functionality implementation it's needed. if you spend a lot of time in pre production designing a system that is decoupled and has clear input/output requierments then patching stuff is going to be a simple matter of refactoring code.

the problem is that people use flow charts for everything, this leads to people just wasting time on designing a small instance of the code that is straightforward.

for instance, if i would make a program to process geographical data from satellites, i would spend a lot of pre production designing the system that parse the data, store it in a database and probably also the format for the data storage. i wouldn't be bothering a lot with the GUI or sound systems because they barely do anything.

it's not enough to know how to make flow charts, you also need to know when to use them and when not to. cutting corners is part of every big project.

 

[Aim64C]

yes, for architecture and system design flow charts can be very helpful, but i don't think that for small programs and functionality implementation it's needed. if you spend a lot of time in pre production designing a system that is decoupled and has clear input/output requierments then patching stuff is going to be a simple matter of refactoring code.

This is very true.

Hell, the way programming is, today, you almost don't need a flow chart for 3d programs... it's all pretty much written out in the API standards what needs to be done.

the problem is that people use flow charts for everything, this leads to people just wasting time on designing a small instance of the code that is straightforward.

I can understand the point of doing it in a class, though. To show how the micro translates to the macro.

Though... honestly... if process flow is that complicated of a process for someone... they are probably in the wrong line of work.

Though it reminds me of what an older teacher and I were talking about one day (he heads up the university's lab detachment for our clinic) - a lot of kids these days are growing up without understanding how math works. They know how to use a calculator - but they don't even understand -what- division is.

Which means we're in ****ing trouble.

for instance, if i would make a program to process geographical data from satellites, i would spend a lot of pre production designing the system that parse the data, store it in a database and probably also the format for the data storage. i wouldn't be bothering a lot with the GUI or sound systems because they barely do anything.

True. Though working a good UI onto a project is always a good idea if you plan it to be more than a back-end or 'development' tool.

But... even then... your UI wouldn't necessarily be doing all that much - you could pretty much wing it and make it functional.

it's not enough to know how to make flow charts, you also need to know when to use them and when not to. cutting corners is part of every big project.

I wouldn't say 'cutting corners' is a part of every project. It's separating excessive and redundant work to allow more time for productive work.

But I work in Dialysis (healthcare) - phrases involving "dead" or "cutting corners" tend to be taboo.

 

[EnDash]

This is very true.

Hell, the way programming is, today, you almost don't need a flow chart for 3d programs... it's all pretty much written out in the API standards what needs to be done.



I can understand the point of doing it in a class, though. To show how the micro translates to the macro.

Though... honestly... if process flow is that complicated of a process for someone... they are probably in the wrong line of work.

Though it reminds me of what an older teacher and I were talking about one day (he heads up the university's lab detachment for our clinic) - a lot of kids these days are growing up without understanding how math works. They know how to use a calculator - but they don't even understand -what- division is.

Which means we're in ****ing trouble.



True. Though working a good UI onto a project is always a good idea if you plan it to be more than a back-end or 'development' tool.

But... even then... your UI wouldn't necessarily be doing all that much - you could pretty much wing it and make it functional.



I wouldn't say 'cutting corners' is a part of every project. It's separating excessive and redundant work to allow more time for productive work.

But I work in Dialysis (healthcare) - phrases involving "dead" or "cutting corners" tend to be taboo.

completly agree, and i remember in a programming lecture i saw once the guy explained that taking out a feature from his program is "like killing my babies". so taboo is in place i think.

 

[Vilvake]

This probably won't help you, but I was bored, so here's a java version:

Spoiler

import java.util.Scanner;


public class Main {

private Scanner input;

public static void main(String[] args){

new Main();

}

public Main(){

input = new Scanner(System.in);

calculateAcres();

}

public void calculateAcres(){

System.out.println("Please enter the total square feet of the tract of land.");

double squareFeet = input.nextDouble();

System.out.println("\nThere are " + (squareFeet / 45356) + " acres in " + squareFeet + " square feet.");

System.out.println("\nDo you want to make another calculation? Please enter 'yes' or 'no'.");

String answer = input.next();

if(answer.equalsIgnoreCase("yes")){

calculateAcres();

}else{

System.out.println("\nHave a nice day.");

}

}

}