Topic: looked at bitcoind source and looks like a shitcode (Read 844 times)

And thank god, this one is especially painful to read. Not sure it's worth anyone's energy.

I see the person who continues to argue against working, secure and efficient code. How will you call such a person?

You expect many similar to yourself in this forum. You are wrong again.
Morons like you constitute an absolute minority here.

U re such an idiot no decent programmer argues against clean code, but i have to concede i do expect to run into tons of idiots on online forum.

Oh LOL, and you are speaking about trolls

You did not answer a single question I asked you. Instead you have concentrated on my modest person. Actually you are trying to troll Bitcoin devs and myself. So I am in good company

You could not read bitcoind code, you could not read the its documentation.
So what else is left to you but to blame others for that.

Maybe (but with very low probability) you will realize that code that you consider "shitcode" successfully runs for almost ten years.

So, go ahead and write your "comments only" coin

 

Stated above i am welcoming arguments not some crackerjack trolls but now you started to picking me on my ass, why don't you get fuck out of my back, wy'a? i am not interested in troll fight with loser like you.

Hm, I do not think that I will continue discussion with a person who consider himself a -->>>>>programer<<<<<--     but cannot even put "quote /quote" brackets correctly.
Saddened, instant karma. 

Hm, I do not think that I will continue discussion with a person who consider himself a programer but cannot even put "quote /quote" brackets correctly.

lease try to read the text to which you are responding.
I wrote about maintaining  the code, not about maintenance free code.

Please try be logical
Few posts above you said that my 40+ years of programing experience do not matter.
Quote
...experience does not really count much after 5-6 yrs...
and now you bring the argument about "respected engineers who is 20-30 years more experience than me".

Firstly, I was referring to the average and below ones who does no grow and stay current with his/her skillset.

For later, I was referring to the top engineers who continually improve their skillset. It has been implied wish you had been noticed it.
This is getting savage. 

Please try to read the text to which you are responding.
I wrote about maintaining  the code, not about maintenance free code.

Please try be logical
Few posts above you said that my 40+ years of programing experience do not matter.
and now you bring the argument about "respected engineers who is 20-30 years more experience than me".

You reference to a a post which states
quite opposite to verbal diarrhea in your example of comments.
 

The design of bitcoin took a complicated problem and made it as complicated as it could possible get
and then spent time fixing design flaws of its own making.

Bit-Torrent produces a useful output of about (Guessing here) 100 gigabytes per second and also had to overcome
design changeless and has stood the test of time but Bitcoin only got as far as 8K per second and most the design
of hashing a file was borrowed from Bit-Torrent and put out as something completely new when it was a re-hash of
something that had already been discovered.

Yes sure mr moderator I know my reply was "off-Topic" again right ! 

i am not saying that it needs to be maintenance free, but to minimize time on maintenance code comment is essential and it is not actual my opinion rather inherited practice that i have worked with respected engineers who is 20-30 years more experience than me were respected by peers. Too many times I have seen software projects eat up endless cycles and resources and it is always done by shitty practices and shoddy design. Of course I am not lecturing you to do the same but the your way of doing will undoubtedly put in the majority of software engineers in the industry who does a poor job. If you involved in a large software project or your own project will grow large and eating more and more of your cycles , you will certainly will feel the need to do a proper commenting. I can not lecture all these stuff here may be you can read through if it makes you interested if not interested i will end the argument here.

https://javarevisited.blogspot.com/2011/08/code-comments-java-best-practices.html

I still disagree with you.
Your comments look like user's help. And probably that many examples are good for user's manual.

But one gets into source code for two reasons: 1. tox fix the bug; 2. to modify the program.
For the person who has to support this program description of fields as comments within the code probably will be more helpful.

But we are speaking about bitcoin code that is successfully running and is being modified from version to version.
And to call this shitcode I consider indecent for the programer.

May be it makes sense to rewrite whole bitcoin kernel using some modern language, like Ethereum did already?
Or favor C++14 and get rid of Boost library?

Example of command line processing function header. My english aint no perfect as it is my second language but that is not the point. It is only few hundred lines of code, believe me I don't ever wanna look at the function's code! I guarantee, it will take days or weeks to figure it out!!

#   The pSysArgv is the all values of sys.argv as it is. This is what the
#   users of particular enters in the command line.
#   The pSupportedArgv is the tuple list of supported arguments in dictionary format passed
#   on by scripts and therefore its contents are specific to a particular script's implementation.
#   However following universal convention are used throughout to enable uniform processing
#   for any or almost any types, variants and number of switches and arguments.
#   Dictionary key holds the name of the argument in the naming convention: "--"
#   Dictionary value holds the tuple list object, serving as an initial indicator implying how many
#   values the arg needs (refer to examples below):
#   Current implementation divides the tuple values as two types in general:
#   1. (, ) - implies literal processing, which means the supportedArgs lists out the
#   actual values that user can enter in the command line for that particular switches and no other
#   allowed value. Example is if particular scripts --drive switches accepts only C: D: E: drive
#   letters and any other drive letters are not allowed.
#   2. ('__range__', ) - implies that there is no restrictions on the values provided by user
#   for particular switch, however the contains the range of number of allowed values for that
#   particular switch. This is useful in case, it is not known what value user will be putting at the
#   command line or there too many possibilities for particular variable.
#   For example, if --ip switches requires one value which is IPv4 address but the range of valid
#   IPv4 is too many to listed out as literal however --ip will accept only one value, in this case
#   supported switch is declared as: ('__range__', 1)
#   if --ip allows up from one to up to 5 different IP address following, (as in the case:
#   --ip 10.24.11.0 10.0.0.1 12.0.0.1 192.168.0.1 172.17.0.0
#   then it should be declared and passed as:
#   ('__range__', 1, 2, 3, 4, 5)
#   or possible:
#   ('__range__', range(0, 5))
#   pSupportedArgs typical examples are below but not limited to:
#   -------------------------------------------------------------------------------------
#   Arg name     Initial indicator of value count, tuple list type   Valid user input
#   -------------------------------------------------------------------------------------
#   '--timeout': (1,),  (needs one and only one value for argument)
#                                                           -> user input --timeout 100
#   '--timeout': ()     (needs no value)                    -> user input --timeout
#   '--timeout': (1,2,3)(needs somewhere between 1 to 3 values, inclusive)
#                                                           -> user input --timeout 1
#                                                           -> user input --timeout 1 100 2
#                                                           -> user input --timeout 1 100
#   !!! This is currently unimplementable, needs to look!!! Currently it is not supported.
#   '--timeout': [1:CONFIG_MAX_ARG_VALUES] (needs somewhere between 1 to CONFIG_MAX_ARG_VALUES
#   number of values, which effectively implies "greater than 1")
#                                                           -> user input --timeout 1
#                                                           -> user input --timeout 1 100 2
#                                                           -> user input --timeout 1 100
#                                                           -> user input --timeout 1 2 3 4 5 6 7
#                                                           -> user input --timeout 1 2 3 4 5 6 7 10 11
#   -------------------------------------------------------------------------------------
#   Once the arguments are processes and validated, the values of the dictionary will be populated
#   with the user supplied values from the command line. If user has not provided the argument, its
#   corresponding dictionary value remain unchanged, tuple list type, implying that the caller script
#   will not process it.
#
#   input:
#   - pSysArgv - sys.argv() as it is.
#   - pSupportedArgs - dictionary type consisting of tuple list of argument that particular calling scripts supports.
#       - key holds the name of the argument.
#       - tuple list type holding indication of how many values are needed for the argument
#        (for details, refer to function header)
#   - helpStringArr - if user input --help argument, use this string to display the help message.
#   output:
#   - pSupportedArgs' values are populated with the validated command line argument values as list type.
#   - if particular argument is not provided by user, value remains unchanged as list tuple type.
#   - EXIT_NO_ERR if --help is supplied.
#     EXIT_ERR on any error condition.

def prepArgs(pSysArgv, pSupportedArgs, helpStringArr):

it is always welcoming to challenging opinions here, save for a few crude nuggets who only wants to bash and troll around.

I can somewhat agree that industry moving forward self descriptive code and you guys put forth a challenge and argument, but still I believe at most companies I worked, the code sucks, and engineering hours are wasted. For large enterprise where million and billions are at stake poor code become actually unfixable.

Self descriptive code that you can glance through will work with smaller project and/or smaller functions with few dozens or hundreds of code, but I have worked with overly convoluted functions that are several thousands lines work and it is a b** to work with. It is always better to describe in literal language with IN/OUT clearly defined like a black box.

Well the OP is a newb, but I will help him,

First of all you are right, Satoshi was not a coder, and nothing in BTC 1.0 is anything a 3rd year CS student hadn't heard of,

IMHO Satoshi was a math-guy, self taught to code,

Here look at the history "Death&taxes" wrote in 2013 here in this forum "Satoshi was a shitty cryptographer, he picked the worst shit around both sha-256 & ecdsa-secp256k1", so there goes the theory that Satoshi was a 'crypto expert' NOT

Sure you look at BTC 1.0 source its terrible, but the reason that 1.5 is clean, is cuz 1,000's of guys have clean up the C++.

Now its been rewritten in python by Buterin, and into GO by others;

The code is NOT commented, for the life of me when people say 'open source' but NO comments I call this obfuscated code, code without comments is just BS, but then nobody is willing to admit this, I'm firmly believe most likely the comments might have been stripped,

BTC was written by a TEAM at NSA, the moniker SATOSHI was just handle to coordinate the dissemination, the actual authors pulled their comments so it would appear the code was written by a solo individual, it was not, this is clear studying 1.0

I agree with the theory that the ppl at NSA weren't smart enough to finish the project, so they released it into the wild.

1.) SHA-256 is NSA
2.) ECDSA SECP256k1 is NSA, paid to certicom, fact
3.) the bitcoin-satoshi white paper is 100% stolen from a 1996 NSA document called 'how to make a mint', funny that NOBODY ever gives NSA the credit for the white-paper? funny huh? http://groups.csail.mit.edu/mac/classes/6.805/articles/money/nsamint/nsamint.htm

Chow  & Maxwell keep the Myths of BTC alive, perhaps paid well by the original, but even more likely they are part of the orginal NSA team, and thus they stand by permanently to 'guide' their child

The above is/was just a little history lesson on btc

It's already BEEN done, its called BITCOIN-GOLD aka BTG, and guess what its owned by the same ppl who own the chinese mining asics in china, they covered their bets by owning the GPU variant of BTC

Even here on this forum, but done  its called BITCOIN-Z, btc-z, its here and trades at 0.0000001 cent, and they made 21 billion of them Again, it uses the exact same GPU hash as EWBF miner, e.g. zcoin

chinese miners own +90% of the biz, IMHO they own this forum by way of amazon(server), which is tied to alibaba, where Ma is partners with the ASIC guys, ... its all a handful of people that control all,

How can you rectify this? U can't, its too late, ... its like a child growing up and realizing he has to get get a job, and can't live with parents forever, someday the HODL'rs wake up and realize the parents are chinese and own it et-al