Programming languages' semantic

[MasterInQuestion]

    "var" vs. "$var": Is it variable or keyword?
    "print" vs. "print()": Is it keyword or function (or method, routine whatsoever) call?

    "${Arbitrary Non-Sense's}"?
    "${ /Array\d+(?:_\d+)?/ }"..?

    "${Array${i}}"?
    `${ "Array" + ( exist ${j} ? "${i}_${j}" : ${i} ) }`?

[[
    print "123" "456"
    print( "123", "456" )
]]
    Significant overhead. But desirable for clarity. [1] [2]
    Interactive vs. Canonical: shortcut for quick input.

[ [1]
    `a 1 b 2`??? [ One such failure: SVG "d" [4]. ]
    `a 1 $( b 2 )`: Unix Shell.
    `a( 1, b( 2 ) )`: Classical functional. ]
[ [2]
    Certain functionality expects no extra input:
    E.g. `goto ":Label"` [3], "break", "break 2"
    .
    Wrapping the parentheses would be excessive. ]

[ [3]
[[
:Label for jump-back; a!
    ...
    goto ":Label for jump-back; a!";
]] ]

[ [4]
    More than 1 way to draw the same curve...
    Much reminds me of the RISC vs. CISC design choice.
    .
    Extreme invert. Excess amok.

    Further reading on SVG: https://github.com/MasterInQuestion/Markup/issues/2 ]


=== Pointer type (reference) cause ===

[[
    ${Variable to Meddle} = Hefty-Whatsoever();
    ${Name of Variable to Meddle} = "Variable to Meddle";

    ObscureMeddling( ${Name of Variable to Meddle} );
]]
    Pass by reference (to the original) [2] or pass by copy (where causes a new instance of "Hefty-Whatsoever" [1]).
    "ObscureMeddling" may have different expectation.
[1] Though compiler may automatically reduce such overhead, to some extent.
[2] Also accomplishable by "eval" alike.

[[
    ${var}
    \${ref}
    ${ \${deref} }
]]
    ... Where exactly C and Perl so on failed: over-abstraction.
    (though not in exactly the same shape, much resembles)

[ "C absurdity"
    https://github.com/FFmpeg/FFmpeg/commit/86f73277bf014e2ce36dd2594f1e0fb8b3bd6661
    https://download.mikroe.com/documents/compilers/mikroc/arm/help/integer_constants.htm
    https://www.tutorialspoint.com/cprogramming/c_data_types.htm
    https://en.wikipedia.org/wiki/C_data_types#Main_types
    (conflicting data types and bizarre logic...)
    .
    https://github.com/FFmpeg/FFmpeg/commit/7a089ed8e049e3bfcb22de1250b86f2106060857
    https://www.cybersecurity-help.cz/vdb/SB2024122032
    [ ^ https://trac.ffmpeg.org/ticket/11537#comment:1 ]

    "uint32_t"
    https://old.reddit.com/r/C_Programming/comments/dj42mi/what_is_the_benefit_of_using_these_data_types/?sort=old#f40sk0o
    [ ^ https://undelete.pullpush.io/r/C_Programming/comments/dj42mi ]
    https://old.reddit.com/r/learnprogramming/comments/ihtow9/what_is_the_difference_between_uint32_t_uint/?sort=old#g32emh7
    .
    https://stackoverflow.com/questions/48833976/failing-to-understand-what-the-expression-uint32-t-does#48834118 ]


=== Type casting directive ===

[[
    [utf16( LE )]
    [utf8( 2,048 )]
    [str( 8,192 )]
    [int( 7 )]
    [bool]
    [int64]
    [float( 32, 8 )]
]]
    Typeless can at the same time be strictly typed.

    These are much used as memory allocation hint: no extra limit imposed on actual parsing.
    Data, are no more than data. It is all upon: the interpretation.

[[
    ( [int8] 128 == all( -128, 128 ) ) == true
    ( -128 == 128 ) == false
]]
    See:


=== See also ===

    Relationship between high-level logic and low-level representation
    https://github.com/MasterInQuestion/talk/discussions/24

[MasterInQuestion]

    Recently I was invited to a questionnaire about code smell detection tools.
    Below is the selected (and refactored, also commented) content:
[[
== Practice and Issue of Code Smell Detection Tools ==

=== |1| Code smell ===

    Code smell refers to the coding style, structure, or design that is:
    |*| Not in specification,
    |*| Does not conform to best practices,
    |*| Or can cause problems in software code.
    .
    These smells may not be straightforward bugs:
    But they can affect the readability, maintainability, and extensibility of the code.

    Code smells are mainly divided into:

==== Class level ====

    Class level code smells, often involve the structure and design of the entire class: reflecting the complexity and maintainability of the class.
    Common class level code smells include:

[ "Data Class"
    The class has only fields (data), methods for getting and setting fields (data).
[[

	public class Person {
	private String firstName;
	private String lastName;

// Constructor:
	public Person (
	String firstName,
	String lastName
	) {
	this.firstName = firstName;
	this.lastName = lastName;
	};

// Getter, Setter:
	public String getFirstName () {
	return firstName;
	};

	public String getLastName () {
	return lastName;
	};

	public void setFirstName ( String firstName ) {
	this.firstName = firstName;
	};

	public void setLastName ( String lastName ) {
	this.lastName = lastName;
	};

	};

]]
    Analysis:
    The "Person" class contains only methods for getting and setting first/last names.
    [ But intended to represent basic information about a person?.. ] ]

[ "God Class"
    The class takes too many responsibilities and functions.
[[

	public class Customer {
// >>>> (0)
	private String name;
	private String address;
	private String phoneNumber;
	private List<Order> orders;
//
//	Constructor, Getter, Setter:
//	Methods that perform various tasks.
//
	public void processOrders () {
// Complex logic involving orders.
	};
//
//	... (more methods)
//	God-like class caring too much.
//
	public void performCustomerTasks () {
	validateCustomerData();
	processOrders();
	sendCustomerEmails();
// ... (more tasks)
	};

	private void validateCustomerData () {
// Complex data validation logic.
	};

	private void sendCustomerEmails () {
// Complex email sending logic.
	};
// <<<< (0)
	};

]]
    Analysis:
    The "Customer" class is not only responsible for basic customer information.
    But also for order processing, data validation, sending emails, and many other duties. ]

==== Method level ====

    Method level code smells, focus on the design and implementation of individual methods: which can involve aspects such as length, complexity, etc. .
    Common method level code smells include:

[ "Feature Envy"
    The methods are more interested in the functionality of other classes than their own functionality.
[[

	public class Car {
	private String color;

	public String getColor () {
	return color;
	};

	};

	public class Driver {
	private Car car;

	public void printCarColor () {
	String carColor = car.getColor();
	System.out.println( "The car's color is: " + carColor );
	};

	};

]]
    Analysis:
    The "printCarColor" method of "Driver" class is over-dependent on the "getColor" method of "Car" class. ]

[ "Long Method"
    The method whose functionality and scope are difficult to understand: i.e. a method that handles a number of different tasks in a single method.
[[

	public class DataProcessor {
// >>>> (0)
	public void processUserData ( User user ) {
// |1| Validate user data:
	if ( user != null ) {
//	Validation logic...

// |2| Process user data:
//	Data processing logic...
	System.out.println( "User data processed successfully." );

// |3| Update user statistics:
//	Statistics update logic...
	System.out.println( "User statistics updated." );

	} else {
	System.out.println( "Invalid user data." );
	};

	};
// <<<< (0)
	};

]]
    Analysis:
    The "processUserData" method is responsible for validating user data, processing user data, and updating user statistics. ]


=== |2| Code smell detection tools ===

    Heuristic based code smell detection tools/technologies extract the software features related to the code smell from the original code:
    Then detect whether the code smells: according to the default rules of the tool, or custom rules according to the need of the project.
    [ There are significant errors in the described Heuristic: fixed best-effort. ]
[[
    Input: "Data Class"
    ->
    Heuristic rules:
    Wc > 1/3
    && ( Npa + Npmi > 3 && Cwm < 31 )
    || ( Npa + Npmi > 5 && Cwm < 47 )
    .
    Wc: Weight of the class.
    Npa: Number of public attributes.
    Npmi: Number of public methods non-static. (non-propagatable, thus inaccessible publicly)
    Cwm: Count of weighted methods.
    ->
    Output:
    DataClass: Class "Person" may be Data Class. (Wc: 0%, Npa: 0, Npmi: 4, Cwm: 5)
]]

    Machine/Deep learning based code smell detection tools/technologies can extract software features from the original code:
    Then input them into the trained model to detect whether the code smells.

    [ Utter non-sense [1]. Probably there's some misunderstanding on machine learning..? ]

[ [1]
    May Boeing count on Junkyard Tornado to assemble planes..?
    Heuristics is a core part of machine learning: Garbage-In, Garbage-Out. ]




== Importance of Code Smell Detection Tools ==

[ "Efficiency and time saving"
    Code smell detection tools can significantly reduce the time and effort required to manually detect code smells. ]

[ "Improve code readability"
    Code smell detection tools can check for redundancy, excessive complexity, and non-standard naming in the code.
    Helping developers improve the readability of the code and make the code easier to understand and maintain. ]

[ "Improve code performance"
    The code smell detection tool can detect performance bottlenecks and inefficient operations in the code:
    Help developers optimize the code, and improve the execution efficiency and response speed of the program. ]

[ "Adherence to coding norms"
    The code smell detection tool can check whether the code conforms to a specific coding specification:
    Help the development team maintain a consistent coding style, and improve the maintainability and team collaboration efficiency of the code. ]

[ "Prevent potential bugs"
    Some code smells can cause future errors.
    And by identifying them in advance: you can reduce the likelihood of errors occurring. ]




== Acceptance of Code Smell Detection Tools ==

[ "Coverage"
    Whether the tool can cover more programming languages and more types of code. ]

[ "Fast processing speed"
    Whether the detection tool can quickly detect the given items, saving the cost of manual inspection. ]

[ "Accuracy"
    Whether the expected results of the inspection are effective and efficient in helping to detect smells in the code.
    And whether they are not significantly different from human inspections. ]

[ "Custom rules and configurations"
    The detection tool can customize the detection methods and rules to meet the needs of different projects. ]

[ "Provide explanations and recommendations"
    The instrumentation tool provides contextual explanations of the results of the inspection and suggests possible refactoring. ]

[ "Improve code quality"
    Whether the code refactored based on the results of the detection is more readable, easier to understand, and easier to maintain. ]

[ "Ease of use"
    Is it easy to install, configure, and learn to use the tool. ]


    Apart from the aforementioned conclusions.
    Do you have any additional thoughts, considerations, or concerns regarding code smell detection tools?

    Specifically, in the era of large language models like ChatGPT:
    What opportunities or challenges do you think these models can bring to code smell detection?
]]
    And my reply:
[[
    Having read most of the questionnaire's content: many of which are inapplicable, or based on invalid promise.
    So I didn't submit and wrote this explaining instead.

    Corest:
    |*| Definition of so called "code smell" invalid:
    Much caused by the over-abstraction (and some thoughtless design) of many programming languages: fundamentally so many aspects don't have to exist. (nor do they really exist at low level)
    Insane decoupling is also not applicable: things are by nature coupled, inseparable.
    .
    |*| To really address the readability problem, what has to be fixed are probably the programming languages themselves:
    Many such problems are really caused by the programming languages' design, the definition.
    Fixing what's based on the rotten base is vain: "治标不治本" (fixing the surface not the core).
]]

    All these are solely designed to solve 1 problem: coders unable to tell what the code does.
    Besides, none.

    To effectively address which, something must be done on the languages themselves.
    Else, none.


    Didn't read carefully enough to notice all details.
    The demos are mostly Java inclined: a language prominent for its Object-Oriented Obfuscation...

    烂泥滩上修高楼: 白搭.
+    Atop rotten mire building high belvedere: Wasteful deployment.