You may want to give an example. If your code focuses too much on language specifics that are not part of the algorithm, then Understandably, it could be said you had non-algorithm mixed with your algorithm, resulting in an incorrect result.
I Feel for the reasoning, the whole point of learning is to show you understand the concept, not to bend over and tick all the right boxes.
A computer can be taught to pass university, but a computer cant be yet taught to actually think for itself and apply knowledge.
Eat and regurgitate mentality is why I never graduated.
With respect to your recent comment, its important to realise pseudocode is undefined. There are generally reused terms in it, but its not a strict language any more than english is ( otherwise it would be a programming language, which could be parsed and executed verbatim )
The importance of pseudocode is to flesh out the logic part of the system and not have to worry overly about the syntax beyond 'it makes sense'
Often this can make the pseudocode both more terse and more understandable.
Pseudocode also doesn't rely on the reader having an understanding of the 'magic syntax' in the language in order to process it, all they need to understand is the terms used.
If you were to give the average person an algorithm in perl for example, most people would just die from horror because they don't see past the screeds of line noise.
While:
sub foo {
my @args = @_ ;
my( $a, $b )=(@args[0],@args[1]);
for( @{ $a } ){
$b .= $_ ;
s/id//g;
}
return [$b,$a];
}
may make some coherent sence to somebody versed in perl, to the average code reader all they get is a "what the hell did you just say" response. Documenting it doesn't help a lot either.
| there is a subroute foo which can take a list of strings, and a default string,
\- which then iterates all items in that list,
| \- and for each item in that list
| 1. appends the contents of that item to the end of the default string
| 2. removes all instances of the string "id" in that item
|
\ and returns a list, which contains
1. the concatentated default string
2. the modified input list
Suddenly it becomes less ambiguous and a greater percentage of peoples can understand it.
So possibly, half the exercise with writing the algorithm is an exercise in "Not only do you have to prove you understand it, you also have to prove you can explain your reasoning to others whom know nothing of the problem" , which is a vital ability you need. If you can't communicate what you have done, nobody can use it.
there's also this nasty little problem with code, that doesn't exist in an algorithm, and that is the code may look right, but may not do what you think it does, and if it doesn't do it right, and you don't realise, people reading the code reverse engineering it will foul it up and copy a broken algorithm. not good. the algorithm in human form better translates 'this is what i want it do do'