Skip to main content
Code Review

Return to Answer

spelling/grammar and formatting
Source Link
Toby Speight
  • 87.9k
  • 14
  • 104
  • 325


Code is short & simple enough that (imoIMO) it should be combined into a single source file, eliminating "app header file" complexities (including procedural code/functions defined in the header file.) This extends to ancillary 'makefile' maintenance, too.





Suggestion: enum { e_DECR, e_ENCR }; as a one line alternative basis.
enum tokens are available to debuggers whereas preprocessor tokens are lost.
Note that shorter token names are easier to distinguish.
Less is more.


  • enum tokens are available to debuggers whereas preprocessor tokens are lost.
  • Note that shorter token names are easier to distinguish.
  • Less is more.





Consider your algorithm with a one-character 'key'. Each enciphered letter is processed exactly the same (easy to break). Consider using a five-character 'key' for a 1000 character message. The key has been 're-used' 200 times (providing lots of repetition for the code-breaker to use to crack the code.).



Trivia: The famous Enigma cipher machine is legendary for its squillions of enciphering possibilities. The wiring between its plugboard and "input rotor" could have been 'scrambled', thereby increasing the number of possibilities to be 1 out of 26! (a VERY large value). Instead, that bit of wiring was established in "ascending alphabetic order". Of the 4 x 10^264✕1026 wiring possibilities, the German'sGermans used THE MOST OBVIOUS ONE... (A major 'oops!')


Code is short & simple enough that (imo) it should be combined into a single source file, eliminating "app header file" complexities (including procedural code/functions defined in the header file.) This extends to ancillary 'makefile' maintenance, too.



Suggestion: enum { e_DECR, e_ENCR }; as a one line alternative basis.
enum tokens are available to debuggers whereas preprocessor tokens are lost.
Note that shorter token names are easier to distinguish.
Less is more.




Consider your algorithm with a one-character 'key'. Each enciphered letter is processed exactly the same (easy to break). Consider using a five-character 'key' for a 1000 character message. The key has been 're-used' 200 times (providing lots of repetition for the code-breaker to use to crack the code.)


Trivia: The famous Enigma cipher machine is legendary for its squillions of enciphering possibilities. The wiring between its plugboard and "input rotor" could have been 'scrambled', thereby increasing the number of possibilities to be 1 out of 26! (a VERY large value). Instead, that bit of wiring was established in "ascending alphabetic order". Of the 4 x 10^26 wiring possibilities, the German's used THE MOST OBVIOUS ONE... (A major 'oops!')


Code is short & simple enough that (IMO) it should be combined into a single source file, eliminating "app header file" complexities (including procedural code/functions defined in the header file.) This extends to ancillary 'makefile' maintenance, too.



Suggestion: enum { e_DECR, e_ENCR }; as a one line alternative basis.

  • enum tokens are available to debuggers whereas preprocessor tokens are lost.
  • Note that shorter token names are easier to distinguish.
  • Less is more.



Consider your algorithm with a one-character 'key'. Each enciphered letter is processed exactly the same (easy to break). Consider using a five-character 'key' for a 1000 character message. The key has been 're-used' 200 times (providing lots of repetition for the code-breaker to use to crack the code).


Trivia: The famous Enigma cipher machine is legendary for its squillions of enciphering possibilities. The wiring between its plugboard and "input rotor" could have been 'scrambled', thereby increasing the number of possibilities to be 1 out of 26! (a VERY large value). Instead, that bit of wiring was established in "ascending alphabetic order". Of the 4✕1026 wiring possibilities, the Germans used THE MOST OBVIOUS ONE... (A major 'oops!')

added 90 characters in body
Source Link
user272752
user272752

Suggestion: enum { e_DECR, e_ENCR }; as a one line alternative basis.
enum tokens are available to debuggers whereas preprocessor tokens are lost.
Note that shorter token names are easier to distinguish.
Less is more.

Suggestion: enum { e_DECR, e_ENCR }; as a one line alternative basis.
Note that shorter names are easier to distinguish.
Less is more.

Suggestion: enum { e_DECR, e_ENCR }; as a one line alternative basis.
enum tokens are available to debuggers whereas preprocessor tokens are lost.
Note that shorter token names are easier to distinguish.
Less is more.

Append a bit of trivia...
Source Link
user272752
user272752

Trivia: The famous Enigma cipher machine is legendary for its squillions of enciphering possibilities. The wiring between its plugboard and "input rotor" could have been 'scrambled', thereby increasing the number of possibilities to be 1 out of 26! (a VERY large value). Instead, that bit of wiring was established in "ascending alphabetic order". Of the 4 x 10^26 wiring possibilities, the German's used THE MOST OBVIOUS ONE... (A major 'oops!')


Trivia: The famous Enigma cipher machine is legendary for its squillions of enciphering possibilities. The wiring between its plugboard and "input rotor" could have been 'scrambled', thereby increasing the number of possibilities to be 1 out of 26! (a VERY large value). Instead, that bit of wiring was established in "ascending alphabetic order". Of the 4 x 10^26 wiring possibilities, the German's used THE MOST OBVIOUS ONE... (A major 'oops!')

Explain suggestion to unify code, and a bit more...
Source Link
user272752
user272752
Loading
Add block 'C strings end with NUL`
Source Link
user272752
user272752
Loading
Source Link
user272752
user272752
Loading
lang-c

AltStyle によって変換されたページ (->オリジナル) /