SOME LOW LEVEL TRICKS TO INCREASE CODE COMPACTNESS

Some tricks here may drastically reduce code readability(or even screw code performance and/or the AST), so using any tricks here should be backed up with really solid reasons, otherwise doing so may end up being extremely bad practices(like increasing code compactness for the sake of increasing code compactness).
Whether or not you're going to use any such dirty little tricks, you may want to know them as some other scripts may use some of them and sometimes you may have to read some of their scripts.

Example 1

It assigns true to var_a and false to var_c if var_b is a TrueClass and var_d is a FalseClass respectively.
As long as both var_a and var_c only cares if they're TrueClass or FalseClass, the below reduced form will work:

If var_b is a TrueClass, var_a will be true as now var_a || var_b returns a TrueClass, otherwise the value of var_a will be unchanged as now var_a || var_b returns the "truth value" of var_a; If var_d is a TrueClass, var_c will be unchanged as now var_c && var_d returns the "truth value" of var_c, otherwise c will be false as now var_c && var_d returns a FalseClass.
Note: ||= and &&= are so useful that any scripter should at least know what they do.

Example 2

It first creates a hash for $imported if it's not already done, then maps the key :script to value ver in $imported.
The below is 1 way to make it more compact:

As contents inside (), which are $imported ||= {}, are run first, ($imported ||= {}) return $imported. Then the key :script will be mapped to value ver in $imported, making it a reduced form of the original codes.
Note: This reduced form is so common among custom RGSS3 scripts that any scripter should at least know what it does. I don't know if the same applies to RGSS and/or RGSS2 though.

Example 3

It returns obj_1 and obj_2 if obj_1 is a TrueClass and FalseClass respectively.
The below is 1 way to make it more compact:

If obj_1 is a TrueClass, obj_1 will be returned as now obj_1 || obj_2 is sure to return a TrueClass, otherwise obj_2 will be returned to determine what obj_1 || obj_2 will return. So it's a reduced form of the original code.
Note: The default RMVXA Game_Variables has this method:

Which uses this reduction trick.

Example 4

It first increases a by b, then runs expr_1 if a is greater than c.
The below is 1 way to make it more compact:

As contents inside (), which are (a += b), are run first, (a += b) returns the new value of a. The that new value of a will be checked if it's greater than c to determine if expr_1 should be run, making it a reduced form of the original codes.

Example 5

It first assigns the value returned by def_1 to a, then passes a as the argument of def_2 and def_3.
The below is 1 way to make it more compact:

As the passed arguments are first run before running the methods passing them, a = def_1 is run before calling def_2. As a still exists after calling def_2, when calling def_3, a still holds that value returned by def_1. So it's a reduced form of the original codes.

Example 6

It runs expr_2 and expr_3 if expr_1 returns a TrueClass.
As long as expr_2 always returns a TrueClass, the below reduced form will work:

If expr_1 returns a FalseClass, both expr_2 and expr_3 won't be run as expr_1 && expr_2 are sure to return a FalseClass; If expr_1 returns a TrueClass, expr_2 will be run to determine what expr_1 && expr_2 will return. As expr_2 always return a TrueClass, expr_1 && expr_2 will also return a TrueClass, causing expr_3 to be run.

Example 7

First expr_1 is run, then expr_3 will be run if expr_2 returns a TrueClass.
As long as expr_1 always returns a TrueClass, the below reduced form will work:

First, expr_1 will always be run, causing expr_2 to be run as expr_1 always returns a TrueClass. Then expr_3 will be run if expr_2 returns a TrueClass as now expr_1 && expr_2 returns a TrueClass; Similarly, expr_3 won't be run if expr_2 returns a FalseClass as now expr_1 && expr_2 returns a FalseClass.
As long as expr_1 always returns a FalseClass, the below reduced form will work:

First, expr_1 will always be run, causing expr_2 to be run as expr_1 always returns a FalseClass. Then expr_3 will be run if expr_2 returns a TrueClass as now expr_1 && expr_2 returns a TrueClass; Similarly, expr_3 won't be run if expr_2 returns a FalseClass as now expr_1 && expr_2 returns a FalseClass.

Example 8

It first uses old_var to store the old value or var, then adds var by var_increment, and finally assigns var_change as the truth value of whether the new value of var is different from its old value.
The below is 1 way to make it more compact:

First, var != (var += var_increment) is run, and the left hand side, var, returns the old value of var, while the right hand side, (var += var_increment), returns the new value of var, causing the whole check to be checking if the old value of var is different from its new value. Then, the result of the check will be assigned to var_change, making it a reduced form of the original codes.
Note: This reduced form uses 1 less variable as well.

Example 9

It assigns obj to @obj and true to @boolean.
As long as obj is always a TrueClass and @boolean always only cares if it stores a TrueClass or FalseClass, the below reduced form will work:

It's because now obj, which is always a TrueClass, is assigned to @boolean, making it a TrueClass.

Again, using any of these tricks should be backed up with very, very solid reasons, or the increased code compactness could be outweighed by far more important factors.
What do you think about code compactness in general? What do you think about these dirty little code reduction tricks? Do you have more such tricks to share here?

Also, feel free to correct me if I made any mistake.